-
Notifications
You must be signed in to change notification settings - Fork 12.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove edition umbrella features. #118802
Conversation
r? @TaKO8Ki (rustbot has picked a reviewer for you, use r? to override) |
Some changes occurred in diagnostic error codes Some changes occurred in src/tools/rustfmt cc @rust-lang/rustfmt |
@@ -429,7 +429,6 @@ E0700: include_str!("./error_codes/E0700.md"), | |||
E0701: include_str!("./error_codes/E0701.md"), | |||
E0703: include_str!("./error_codes/E0703.md"), | |||
E0704: include_str!("./error_codes/E0704.md"), | |||
E0705: include_str!("./error_codes/E0705.md"), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please put it back and update the explanation to say it's not emitted anymore (CI will fail in any case explaining this too 😉).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep. I saw others were "removed" and didn't bother to read all the comments.
This comment has been minimized.
This comment has been minimized.
e974fe4
to
f0255e4
Compare
☔ The latest upstream changes (presumably #116952) made this pull request unmergeable. Please resolve the merge conflicts. |
@@ -1,3 +1,5 @@ | |||
#### Note: this error code is no longer emitted by the compiler. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You'll need to remove E0705
from the code blocks labels below as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, I was a little confused why that wasn't generating an error. The rust2018
tag was incorrect, and was causing rustdoc to ignore the code block.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh interesting. Might be interesting to add a check for that then. Adding that to my todo list.
f0255e4
to
6a94733
Compare
6a94733
to
f481596
Compare
@bors r+ |
…KO8Ki Remove edition umbrella features. In the 2018 edition, there was an "umbrella" feature `#[feature(rust_2018_preview)]` which was used to enable several other features at once. This umbrella mechanism was not used in the 2021 edition and likely will not be used in 2024 either. During 2018 users reported that setting the feature was awkward, especially since they already needed to opt-in via the edition mechanism. This PR removes this mechanism because I believe it will not be used (and will clean up and simplify the code). I believe that there are better ways to handle features and editions. In short: - For highly experimental features, that may or may not be involved in an edition, they can implement regular feature gates like `tcx.features().my_feature`. - For experimental features that *might* be involved in an edition, they should implement gates with `tcx.features().my_feature && span.at_least_rust_20xx()`. This requires the user to still specify `#![feature(my_feature)]`, to avoid disrupting testing of other edition features which are ready and have been accepted within the edition. - For experimental features that have graduated to definitely be part of an edition, they should implement gates with `tcx.features().my_feature || span.at_least_rust_20xx()`, or just remove the feature check altogether and just check `span.at_least_rust_20xx()`. - For relatively simple changes, they can skip the whole feature gating thing and just check `span.at_least_rust_20xx()`, and rely on the instability of the edition itself (which requires `-Zunstable-options`) to gate it. I am working on documenting all of this in the rustc-dev-guide.
…KO8Ki Remove edition umbrella features. In the 2018 edition, there was an "umbrella" feature `#[feature(rust_2018_preview)]` which was used to enable several other features at once. This umbrella mechanism was not used in the 2021 edition and likely will not be used in 2024 either. During 2018 users reported that setting the feature was awkward, especially since they already needed to opt-in via the edition mechanism. This PR removes this mechanism because I believe it will not be used (and will clean up and simplify the code). I believe that there are better ways to handle features and editions. In short: - For highly experimental features, that may or may not be involved in an edition, they can implement regular feature gates like `tcx.features().my_feature`. - For experimental features that *might* be involved in an edition, they should implement gates with `tcx.features().my_feature && span.at_least_rust_20xx()`. This requires the user to still specify `#![feature(my_feature)]`, to avoid disrupting testing of other edition features which are ready and have been accepted within the edition. - For experimental features that have graduated to definitely be part of an edition, they should implement gates with `tcx.features().my_feature || span.at_least_rust_20xx()`, or just remove the feature check altogether and just check `span.at_least_rust_20xx()`. - For relatively simple changes, they can skip the whole feature gating thing and just check `span.at_least_rust_20xx()`, and rely on the instability of the edition itself (which requires `-Zunstable-options`) to gate it. I am working on documenting all of this in the rustc-dev-guide.
…llaumeGomez Rollup of 5 pull requests Successful merges: - rust-lang#118417 (Add unstable `-Zdefault-hidden-visibility` cmdline flag for `rustc`.) - rust-lang#118661 (Restore `const PartialEq`) - rust-lang#118802 (Remove edition umbrella features.) - rust-lang#118807 (Remove an allocation in min_stack) - rust-lang#118812 (rustdoc-search: do not treat associated type names as types) r? `@ghost` `@rustbot` modify labels: rollup
…llaumeGomez Rollup of 3 pull requests Successful merges: - rust-lang#118802 (Remove edition umbrella features.) - rust-lang#118807 (Remove an allocation in min_stack) - rust-lang#118812 (rustdoc-search: do not treat associated type names as types) r? `@ghost` `@rustbot` modify labels: rollup
Rollup merge of rust-lang#118802 - ehuss:remove-edition-preview, r=TaKO8Ki Remove edition umbrella features. In the 2018 edition, there was an "umbrella" feature `#[feature(rust_2018_preview)]` which was used to enable several other features at once. This umbrella mechanism was not used in the 2021 edition and likely will not be used in 2024 either. During 2018 users reported that setting the feature was awkward, especially since they already needed to opt-in via the edition mechanism. This PR removes this mechanism because I believe it will not be used (and will clean up and simplify the code). I believe that there are better ways to handle features and editions. In short: - For highly experimental features, that may or may not be involved in an edition, they can implement regular feature gates like `tcx.features().my_feature`. - For experimental features that *might* be involved in an edition, they should implement gates with `tcx.features().my_feature && span.at_least_rust_20xx()`. This requires the user to still specify `#![feature(my_feature)]`, to avoid disrupting testing of other edition features which are ready and have been accepted within the edition. - For experimental features that have graduated to definitely be part of an edition, they should implement gates with `tcx.features().my_feature || span.at_least_rust_20xx()`, or just remove the feature check altogether and just check `span.at_least_rust_20xx()`. - For relatively simple changes, they can skip the whole feature gating thing and just check `span.at_least_rust_20xx()`, and rely on the instability of the edition itself (which requires `-Zunstable-options`) to gate it. I am working on documenting all of this in the rustc-dev-guide.
Note: This PR has broken the cargo nightly tests. See: rust-lang/cargo#13152 (comment) |
…, r=notriddle Add rustX check to codeblock attributes lint We discovered this issue [here](rust-lang#118802 (comment)). I assume that the issue will be present in other places outside of the compiler so it's worth adding a check for it. First commit is just a small cleanup about variables creation which was a bit strange (at least more than necessary). r? `@notriddle`
…, r=notriddle Add rustX check to codeblock attributes lint We discovered this issue [here](rust-lang#118802 (comment)). I assume that the issue will be present in other places outside of the compiler so it's worth adding a check for it. First commit is just a small cleanup about variables creation which was a bit strange (at least more than necessary). r? ``@notriddle``
Note: this section of the rustc-dev-guide needs updating, to remove the bits about editions. |
Thanks for the heads up! Posted the fix at rust-lang/rustc-dev-guide#1836. |
…, r=notriddle Add rustX check to codeblock attributes lint We discovered this issue [here](rust-lang#118802 (comment)). I assume that the issue will be present in other places outside of the compiler so it's worth adding a check for it. First commit is just a small cleanup about variables creation which was a bit strange (at least more than necessary). r? ```@notriddle```
Rollup merge of rust-lang#118872 - GuillaumeGomez:codeblock-attr-lint, r=notriddle Add rustX check to codeblock attributes lint We discovered this issue [here](rust-lang#118802 (comment)). I assume that the issue will be present in other places outside of the compiler so it's worth adding a check for it. First commit is just a small cleanup about variables creation which was a bit strange (at least more than necessary). r? ```@notriddle```
…KO8Ki Remove edition umbrella features. In the 2018 edition, there was an "umbrella" feature `#[feature(rust_2018_preview)]` which was used to enable several other features at once. This umbrella mechanism was not used in the 2021 edition and likely will not be used in 2024 either. During 2018 users reported that setting the feature was awkward, especially since they already needed to opt-in via the edition mechanism. This PR removes this mechanism because I believe it will not be used (and will clean up and simplify the code). I believe that there are better ways to handle features and editions. In short: - For highly experimental features, that may or may not be involved in an edition, they can implement regular feature gates like `tcx.features().my_feature`. - For experimental features that *might* be involved in an edition, they should implement gates with `tcx.features().my_feature && span.at_least_rust_20xx()`. This requires the user to still specify `#![feature(my_feature)]`, to avoid disrupting testing of other edition features which are ready and have been accepted within the edition. - For experimental features that have graduated to definitely be part of an edition, they should implement gates with `tcx.features().my_feature || span.at_least_rust_20xx()`, or just remove the feature check altogether and just check `span.at_least_rust_20xx()`. - For relatively simple changes, they can skip the whole feature gating thing and just check `span.at_least_rust_20xx()`, and rely on the instability of the edition itself (which requires `-Zunstable-options`) to gate it. I am working on documenting all of this in the rustc-dev-guide.
In the 2018 edition, there was an "umbrella" feature
#[feature(rust_2018_preview)]
which was used to enable several other features at once. This umbrella mechanism was not used in the 2021 edition and likely will not be used in 2024 either. During 2018 users reported that setting the feature was awkward, especially since they already needed to opt-in via the edition mechanism.This PR removes this mechanism because I believe it will not be used (and will clean up and simplify the code). I believe that there are better ways to handle features and editions. In short:
tcx.features().my_feature
.tcx.features().my_feature && span.at_least_rust_20xx()
. This requires the user to still specify#![feature(my_feature)]
, to avoid disrupting testing of other edition features which are ready and have been accepted within the edition.tcx.features().my_feature || span.at_least_rust_20xx()
, or just remove the feature check altogether and just checkspan.at_least_rust_20xx()
.span.at_least_rust_20xx()
, and rely on the instability of the edition itself (which requires-Zunstable-options
) to gate it.I am working on documenting all of this in the rustc-dev-guide.