Skip to content
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

Merged
merged 1 commit into from
Dec 11, 2023
Merged

Conversation

ehuss
Copy link
Contributor

@ehuss ehuss commented Dec 10, 2023

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.

@rustbot
Copy link
Collaborator

rustbot commented Dec 10, 2023

r? @TaKO8Ki

(rustbot has picked a reviewer for you, use r? to override)

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Dec 10, 2023
@rustbot
Copy link
Collaborator

rustbot commented Dec 10, 2023

Some changes occurred in diagnostic error codes

cc @GuillaumeGomez

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"),
Copy link
Member

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 😉).

Copy link
Contributor Author

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.

@rust-log-analyzer

This comment has been minimized.

@bors
Copy link
Contributor

bors commented Dec 10, 2023

☔ 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.
Copy link
Member

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.

Copy link
Contributor Author

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.

Copy link
Member

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.

@TaKO8Ki
Copy link
Member

TaKO8Ki commented Dec 11, 2023

@bors r+

@bors
Copy link
Contributor

bors commented Dec 11, 2023

📌 Commit f481596 has been approved by TaKO8Ki

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Dec 11, 2023
GuillaumeGomez added a commit to GuillaumeGomez/rust that referenced this pull request Dec 11, 2023
…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.
GuillaumeGomez added a commit to GuillaumeGomez/rust that referenced this pull request Dec 11, 2023
…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.
bors added a commit to rust-lang-ci/rust that referenced this pull request Dec 11, 2023
…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
bors added a commit to rust-lang-ci/rust that referenced this pull request Dec 11, 2023
…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
@bors bors merged commit 54d6bde into rust-lang:master Dec 11, 2023
11 checks passed
@rustbot rustbot added this to the 1.76.0 milestone Dec 11, 2023
rust-timer added a commit to rust-lang-ci/rust that referenced this pull request Dec 11, 2023
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.
@Rustin170506
Copy link
Member

Note: This PR has broken the cargo nightly tests. See: rust-lang/cargo#13152 (comment)

matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Dec 12, 2023
…, 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`
GuillaumeGomez added a commit to GuillaumeGomez/rust that referenced this pull request Dec 12, 2023
…, 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``
@nnethercote
Copy link
Contributor

Note: this section of the rustc-dev-guide needs updating, to remove the bits about editions.

@ehuss
Copy link
Contributor Author

ehuss commented Dec 13, 2023

Thanks for the heads up! Posted the fix at rust-lang/rustc-dev-guide#1836.

workingjubilee added a commit to workingjubilee/rustc that referenced this pull request Dec 13, 2023
…, 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```
rust-timer added a commit to rust-lang-ci/rust that referenced this pull request Dec 13, 2023
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```
calebcartwright pushed a commit to calebcartwright/rust that referenced this pull request Jun 22, 2024
…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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants