Updates to edition handling. #9184
Conversation
There shouldn't be any functional changes here. * Some doc comments. * Construct `FixArgs` at once so it doesn't need to bother with unnecessary Options. * Remove IdiomEditionMismatch, it is not used. * Use a general deduping mechanism for fix messages.
What was previously "Fixing" was a message for after the fixes had been applied. I think it would be clearer if it said "Fixed", to indicate that the fixes had actually finished. The new "Fixing" is posted just before it starts. This is verbose-only since it is a little noisy.
This helps indicate which edition you are moving from and to.
This is intended to help make it easier to test the 2021 edition.
* `--edition` always means "next" edition. * `--edition` when on the most recent edition is not an error, just a warning. * Support fix to 2021 edition.
# Conflicts: # src/cargo/ops/fix.rs # src/doc/src/reference/unstable.md
|
r? @Eh2406 (rust-highfive has picked a reviewer for you, use r? to override) |
rust-highfive
added
the
S-waiting-on-review
|
Opening as a draft to get feedback. |
|
Oh, I'd also like to remove |
src/cargo/util/toml/mod.rs
Outdated
| } else { | ||
| None | ||
| } | ||
| } |
There was a problem hiding this comment.
I sort of forget the implications of this, can you remind me? What I'm worried about is a set of workspace crates that have mixed editions, but you could do that today as well with a set of crates in a workspace using different resolver versions too. How does Cargo handle that?
There was a problem hiding this comment.
The resolver is always global for a workspace, so if there is some workspace member that specifies resolver="2", that is ignored (only the top-level matters).
However, thanks for pointing this out. There was a bug where if you set 2021 in a member, it would warn about the resolver being set incorrectly. I pushed a change where the default resolver behavior is now set in one place.
This attempts to centralize all the edition stuff in one place (the `Edition` enum) so that adding a new edition or stabilizing one should be relatively little work (and more importantly, we don't miss things). Importantly, this changes `cargo new` to default to the latest stable. It also changes the `cargo fix --edition-idiom` behavior to only apply idioms for the *current* edition.
This was deprecated, never officially part of the stable release.
ehuss
force-pushed
the
fix-next-edition
branch
from
b77c8a2
to
6639dff
Compare
This fixes an issue where warnings would be printed for packages migrating to 2021 in a workspace (that the "resolver" field is ignored, which is wrong). This also places the default resolver logic in one place, and should make it easier to update later.
ehuss
force-pushed
the
fix-next-edition
branch
from
6639dff
to
a82a23c
Compare
Yea, that was my question above. My only concern is that regarding RFC 2906, until that is implemented, then the only thing the I'm fine with adding it, I just wanted to check what you think about that. |
|
Oh I was under the assumption that an implementation of In any case I agree that if the only purpose is to update the |
|
OK, I think this should be ready to go. |
|
@bors: r+ |
|
📌 Commit a82a23c has been approved by |
bors
added
S-waiting-on-bors
|
☀️ Test successful - checks-actions |
Update cargo 11 commits in bf5a5d5e5d3ae842a63bfce6d070dfd438cf6070..572e201536dc2e4920346e28037b63c0f4d88b3c 2021-02-18 15:49:14 +0000 to 2021-02-24 16:51:20 +0000 - Pass the error message format to rustdoc (rust-lang/cargo#9128) - Fix test target_in_environment_contains_lower_case (rust-lang/cargo#9203) - Fix hang on broken stderr. (rust-lang/cargo#9201) - Make it more clear which module is being tested when running cargo test (rust-lang/cargo#9195) - Updates to edition handling. (rust-lang/cargo#9184) - Add --cfg and --rustc-cfg flags to output compiler configuration (rust-lang/cargo#9002) - Run rustdoc doctests relative to the workspace (rust-lang/cargo#9105) - Add support for [env] section in .cargo/config.toml (rust-lang/cargo#9175) - Add schema field and `features2` to the index. (rust-lang/cargo#9161) - Document the default location where cargo install emitting build artifacts (rust-lang/cargo#9189) - Do not exit prematurely if anything failed installing. (rust-lang/cargo#9185)
`cargo fix --edition`: extend warning when on latest edition This extends the warning issued when `cargo fix --edition` is run when the user is already on the latest edition. Before #9184, there were instructions on what to do, but those probably should not have been completely removed. It seems likely that some users may get the steps out of order, so this hopefully tries to explain them clearly.
This introduces some updates for edition handling (split into commits for review). In short:
cargo-features = ["edition2021"]can be used to opt-in to 2021 support without needing to pass around-Z unstable-options. I tried to emphasize in the docs that this is only for testing and experimentation."2"the default resolver for 2021 edition.cargo fix --editionmean the "next" edition from the present one, and support 2021. Also, if already at the latest edition, generate a warning instead an error.cargo fix --editionfrom 2018 to 2021 on the nightly channel without an explicit opt-in. It's tricky to implement with an opt-in (see comment in diff).Partial for #9048.
Fixes #9047.