Suggest removing `#![feature]` for library features that have been stabilized by vishadGoyal · Pull Request #89012 · rust-lang/rust

vishadGoyal · 2021-09-16T14:04:34Z

Issue: #88802
Delayed the check if #![feature] has been used to enable lib features in a non-nightly build to occur after TyCtxt has been constructed.

rust-highfive · 2021-09-16T14:04:37Z

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @matthewjasper (or someone else) soon.

Please see the contribution instructions for more information.

jyn514

Isn't the point to suggest removing the feature? This looks like you've just duplicated the check later into the compiler.

jyn514 · 2021-09-16T14:12:38Z

What is this check doing? It should never be hit since there will always be some features built-in, but it also doesn't seem to have anything to do with the rest of the code.

The lang_features vector contains the declared_lang_features in the session. So only the ones which have been enabled show up here.
I've added this check to skip emitting an error if only lib_features have been enabled and no lang_features

Ok. That still seems like the wrong check, though - if there's one language and one library feature, it should still suggest removing the stable library feature.

How will that be possible since the suggestion can be generated only after TyCtxt is generated? And we will be throwing an error at the parsing stage if a lang feature has been enabled, the compiler will abort and won't go to the next stage

And we will be throwing an error at the parsing stage if a lang feature has been enabled, the compiler will abort and won't go to the next stage
Oh hmm, good point. Ok, this seems fine then - if the language feature wasn't stable removing the library feature wouldn't have helped anyway.

vishadGoyal · 2021-09-16T14:28:26Z

Isn't the point to suggest removing the feature? This looks like you've just duplicated the check later into the compiler.

The warnings for unnecessary use of #![feature] are already emitted in this check. After my changes, it also emits an error if appropriate.
Behaviour:

jyn514 · 2021-09-16T14:30:15Z

Ah! That's perfect then :) can you add that as a test case? It would go somewhere in src/test/ui - anywhere other than issues/ is probably fine.

vishadGoyal · 2021-09-16T15:33:04Z

Ah! That's perfect then :) can you add that as a test case? It would go somewhere in src/test/ui - anywhere other than issues/ is probably fine.

@jyn514 Is there a way to specify which channel the test should be run on? I'm adding a sample code to reproduce this situation and adding the expected stderr output. However, this will be different for different channels (beta, nightly, etc.)

jyn514 · 2021-09-16T16:23:37Z

@jyn514 Is there a way to specify which channel the test should be run on? I'm adding a sample code to reproduce this situation and adding the expected stderr output. However, this will be different for different channels (beta, nightly, etc.)

No, unfortunately, I forgot about that. If you do a manual test and post the output that's good enough.

vishadGoyal · 2021-09-16T16:28:07Z

Manual test:

Is this good enough? @jyn514

jyn514 · 2021-09-16T16:46:14Z

@vishadGoyal how does it behave when there's both a library feature and at least one language feature (e.g. #![feature(never_type_fallback)])?

vishadGoyal · 2021-09-16T16:52:45Z

@vishadGoyal how does it behave when there's both a library feature and at least one language feature (e.g. #![feature(never_type_fallback)])?

I guess that's functional but not exactly what I had in mind.

jyn514 · 2021-09-16T18:14:42Z

@bors r+ squash

Thanks!

bors · 2021-09-16T18:15:06Z

📌 Commit b53c0eb242065377b989d77dba6a113926eb9ef5 has been approved by jyn514

If #![feature] is used outside the nightly channel for only lib features, the check will be delayed to the stability pass after parsing. This is done so that appropriate help messages can be shown if the #![feature] has been used needlessly

Mark-Simulacrum · 2021-09-16T18:23:22Z

@bors r=jyn514 squash-

Squashed the commits locally -- I don't think we've fixed that to behave well in bors just yet.

bors · 2021-09-16T18:23:23Z

📌 Commit 9f7e281 has been approved by jyn514

…laumeGomez Rollup of 10 pull requests Successful merges: - rust-lang#86422 (Emit clearer diagnostics for parens around `for` loop heads) - rust-lang#87460 (Point to closure when emitting 'cannot move out' for captured variable) - rust-lang#87566 (Recover invalid assoc type bounds using `==`) - rust-lang#88666 (Improve build command for compiler docs) - rust-lang#88899 (Do not issue E0071 if a type error has already been reported) - rust-lang#88949 (Fix handling of `hir::GenericArg::Infer` in `wrong_number_of_generic_args.rs`) - rust-lang#88953 (Add chown functions to std::os::unix::fs to change the owner and group of files) - rust-lang#88954 (Allow `panic!("{}", computed_str)` in const fn.) - rust-lang#88964 (Add rustdoc version into the help popup) - rust-lang#89012 (Suggest removing `#![feature]` for library features that have been stabilized) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup

rust-highfive assigned matthewjasper Sep 16, 2021

rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Sep 16, 2021

vishadGoyal mentioned this pull request Sep 16, 2021
Missing help when trying to enable stabilized library feature on stable #88802
Closed

jyn514 changed the title ~~Issue 88802 fix~~Suggest removing #![feature] for library features that have been stabilizedSep 16, 2021

jyn514 suggested changes Sep 16, 2021
View reviewed changes

jyn514 assigned jyn514 and unassigned matthewjasper Sep 16, 2021

jyn514 added A-stability Area: `#[stable]`, `#[unstable]` etc. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Sep 16, 2021

This comment has been minimized.
Sign in to view

jyn514 reviewed Sep 16, 2021
View reviewed changes

Comment threadcompiler/rustc_passes/src/stability.rs Outdated

vishadGoyal force-pushed the issue-88802-fix branch from a1ca7e6 to 745a1c0Compare September 16, 2021 14:47

jyn514 reviewed Sep 16, 2021
View reviewed changes

Comment threadcompiler/rustc_ast_passes/src/feature_gate.rs Outdated

jyn514 added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Sep 16, 2021

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-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Sep 16, 2021

delay error for enabling unstable lib features
9f7e281
If #![feature] is used outside the nightly channel for only lib features, the check will be delayed to the stability pass after parsing. This is done so that appropriate help messages can be shown if the #![feature] has been used needlessly

Mark-Simulacrum force-pushed the issue-88802-fix branch from b53c0eb to 9f7e281Compare September 16, 2021 18:22

vishadGoyal requested a review from jyn514 September 16, 2021 19:13

GuillaumeGomez mentioned this pull request Sep 17, 2021
Rollup of 10 pull requests #89047
Merged

bors merged commit 101a88f into rust-lang:masterSep 17, 2021

rustbot added this to the 1.57.0 milestone Sep 17, 2021

compiler-errors mentioned this pull request Jul 10, 2024
Report usage of lib features in ast validation #127587
Merged

Uh oh!

Uh oh!

Conversation

vishadGoyal commented Sep 16, 2021• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rust-highfive commented Sep 16, 2021

Uh oh!

jyn514 left a comment

Choose a reason for hiding this comment

Uh oh!

jyn514Sep 16, 2021

Choose a reason for hiding this comment

Uh oh!

vishadGoyalSep 16, 2021

Choose a reason for hiding this comment

Uh oh!

jyn514Sep 16, 2021

Choose a reason for hiding this comment

Uh oh!

vishadGoyalSep 16, 2021

Choose a reason for hiding this comment

Uh oh!

jyn514Sep 16, 2021

Choose a reason for hiding this comment

Uh oh!

Uh oh!

This comment has been minimized.

vishadGoyal commented Sep 16, 2021

Uh oh!

Uh oh!

jyn514 commented Sep 16, 2021• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

vishadGoyal commented Sep 16, 2021

Uh oh!

jyn514 commented Sep 16, 2021

Uh oh!

vishadGoyal commented Sep 16, 2021

Uh oh!

jyn514 commented Sep 16, 2021• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

vishadGoyal commented Sep 16, 2021

Uh oh!

jyn514 commented Sep 16, 2021

Uh oh!

bors commented Sep 16, 2021

Uh oh!

Mark-Simulacrum commented Sep 16, 2021

Uh oh!

bors commented Sep 16, 2021

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

8 participants

vishadGoyal commented Sep 16, 2021•
edited
Loading

jyn514 commented Sep 16, 2021•
edited
Loading

jyn514 commented Sep 16, 2021•
edited
Loading