Change:
} #[test] <ins> fn test_url_with_port_parse_and_format() { let url = ~"http://rust-lang.org:80/doc"; assert_eq!(from_str(url).unwrap().to_str(), url); } #[test] </ins> fn test_scheme_host_only_url_parse_and_format() { let url = ~"http://rust-lang.org"; assert_eq!(from_str(url).unwrap().to_str(), url);

Discussion:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --I tried to update a project with the following dependencies: (Just having an empty project with those dependencies sufficient to reproduce the issue) I executed the following commands as : I expected to see this happen: Everything succeeds without errors Instead, this happened: The final check commando fails with error messages The final error message already gives an indication why this error happens. (As already outlined and I feel that this change is nothing that is covered by any edition RFC, as any RFC states that changing the edition should be a crate local change and should not affect any upstream or down stream crates. That's at least in my opinion clearly not the case here. That written I accept that removing this feature from the 2021 edition will likely not happen so let's stop that discussion here ) To give a more productive indication on how that workflow can be improved: In an ideal world would just fix the problem and either add the corresponding section to It would be possible that just sets in the resolver = "2"` rather than just changing the default) As another show stop measurement should emit the same warning as already does. As the messaging currently reads it's unclear if the build will fail afterwards or not. Only gives the user a clear indication how to actually fix that problem As a medium term thing: Rust needs to provide better tools to bundle proc macro crates and other crates. <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace</summary<p</p</details label +A-edition-2021
Thanks for your bug report. This is expected with Cargo's new . See the note that produced: But I'm guessing you're aware of that, considering you reported that issue that's linked there, , and you're the one who suggested adding this very notice and the suggestion.
Yes I'm well aware of this. I've raised this bug report because I do not feel that these messages are on the level that is expected for the edition migration mechanism. As far as I'm aware most of them where written with in mind not with the automatic edition transition.

I feel at least they should be improved. After all the corresponding RFC states that updating to a new edition should be possible by just doing the commands listed above. (That all written it is unfortunately not possible to fix that on diesels side as fixing this does require a major version bump. At least in my opinion this is very unfortunate that such a change is "forced" by the language itself without offering the necessary tools to circumvent those issues at library level.)
I'm assuming that was not done that automatically because it's hard to make sure it's correct. I'm assuming you know more about this? Our goal with the automatic migrations was never to be fully perfect. The edition blog post states: "The automated migrations are not necessarily perfect: there might be some corner cases where manual changes are still required." We aimed for at least 95%+ of crates to be able to automatically migrate without any manual intervention, and have reached a much higher number. The diesel-related failures found during the crater runs amounted to 0.07% of the tested crates. All resolver-related problems totaled to less than 0.5%, of which almost all are an old version of not passing the feature on to a dependency, which has already been solved in a patch release more than a year ago. Cargo already warns about all resolver related changes during the migration, and for errors even explains the issue and suggests the change that's necessary, which you've suggested multiple times as an acceptable solution. We can try to improve even further and make even more edge cases migrate automatically, and I'd definitely welcome such contributions. But I think we're already far past the point of deminishing returns. Especially considering this is a volunteer project with very limited resources. Feel free to suggest a better message to display from . The current message is . Feel free to send a PR, or just leave your suggested improvement as a comment here. Agreed. I'd be very happy to see a concrete proposal for that. :)
Yea, unfortunately we don't have the capability to modify TOML files in cargo at this time.
We aimed for at least 95%+ of crates to be able to automatically migrate without any manual intervention, and have reached a much higher number. The diesel-related failures found during the crater runs amounted to 0.07% of the tested crates.

All resolver-related problems totaled to less than 0.5%, of which almost all are an old version of mimeguess not passing the unicase feature on to a dependency, which has already been solved in a patch release more than a year ago. Thanks for clarifying that. I've looked again into the corresponding RFC and you are right, both state that automated migrations should only work in most of the cases. Doing a crater run is there definitively a way to measure the breakage, but I'm not sure if that's the correct interpretation of the result numbers. The combination + tend to get used in binary rust project, so server side applications and such stuff. I assume that this code large parts of code dependent on both crates is not available on For example itself depends on diesel and diesel_migrations and is not available as crate on There is likely much more non public code with the same problem, so I assume that the real numbers are quite a bit larger here. That written another thing I noticed while reading and is that RFC 2052 states the following: () As of now that's not the case for the example provided. It compiles without any warning using the 2018 edition, but fails to compile with the 2021 edition. Let me clarify that I only suggested that this is an acceptable workaround for the situation where people manually switch to the new behaviour, not for automatically switching that as part of the much more prominent edition release. It's totally understandable to have such an approach but please keep in mind that you only shift the work from one volunteer project (cargo and the edition upgrade) to another one (diesel). Additionally you are doing this without given us any tool to handle this situation in any way, at least not without releasing a breaking change release at least while using . It would already be an improvement if would emit the same message as later on. The later message provides a clear indication on what needs to be done, while the first message only says that there may be some problem. I feel that just require to set the explicitly on the 2021 edition (and default to for new projects) would likely be a better solution.
Note that next to all the crates from , crater also tests all crates from public GitHub repositories that have a file. That second group is actually the majority. (Crater tests about 170k-180k crates. has 67k crates.)

a way to fix this in diesel without issuing a breaking release. It would be great if the message in could be adjusted so that it does not show up if the diesel version is = 1.4.8. Otherwise the message should prompt the user to update diesel to the latest release.
I've issued a new diesel (1.4.8) to address this. Would be great to get the messages updated on cargo/rusts side till the next release. If someone points me into the right direction (reading where to change that + where to open a PR) I might find some time to work on this this week.
That's good news! Are you suggesting that the messages can be removed? Here are the two places: For fix:  For normal builds: 
I think it's better to change the message in such a way that it just suggests updating diesel instead of completely removing the message. I've opened a PR() for this.
When trying to run cargo fix on TrueNAS Core 13.0 via shell in the .cargo directory, I only get the response: error: could not find "" in "" or any parent directory. Trying to go deeper in the tree: cd bin Still the same response. Hope someone can help me...