Repository navigation
Missing help when trying to enable stabilized library feature on stable #88802
Description
Given the following code:
#![feature(discriminant_value)]
fn main() {
let y = Some(1);
println!("{:?}", std::mem::discriminant(&y));
}The current output is:
error[E0554]: `#![feature]` may not be used on the stable release channel
--> src/main.rs:1:1
|
1 | #![feature(discriminant_value)]
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Ideally the output should look like:
error: ...
help: the feature `discriminant_value` has been stable since 1.21.0 and no longer requires an attribute to enable
(or it could be downgraded from error to warning)
#83722 fixed this for #![feature(min_const_generics)] but not for #![feature(discriminant_value)], somehow
Metadata
Metadata
Assignees
Labels
Area: Messages for errors, warnings, and lintsArea: `#[stable]`, `#[unstable]` etc.Call for participation: Medium difficulty. Experience needed to fix: Intermediate.Call for participation: This issue has a mentor. Use #t-compiler/help on Zulip for discussion.Relevant to the compiler team, which will review and decide on the PR/issue.
Activity
jyn514 commentedon Sep 10, 2021
Hmm, this might be because it's a library feature and not a language feature?
jyn514 commentedon Sep 10, 2021
Mentoring instructions: include library features in this check:
rust/compiler/rustc_ast_passes/src/feature_gate.rs
Line 723 in 497ee32
[-]Missing help when trying to enable stabilized feature on stable[/-][+]Missing help when trying to enable stabilized library feature on stable[/+]chansuke commentedon Sep 11, 2021
@rustbot claim
vishadGoyal commentedon Sep 11, 2021
Hi! I started working on this but didn't know I had to claim it first. It's my first time contributing to open source.
Anyway, so far I realized we need to combine these two Vectors instead of just using the declared_lang_features vector
the vectors
use of features
The remaining challenge is to combine two vectors with different data types.
Hope this helps @chansuke Best of luck!
chansuke commentedon Sep 11, 2021
@vishadGoyal I appreciate your great work. You should work on this :)
vishadGoyal commentedon Sep 11, 2021
@rustbot claim
10 remaining items
jyn514 commentedon Sep 13, 2021
@vishadGoyal yes, queries can only be run through a TyCtxt. No, I wouldn't expect so, there's the ast::Attributes but you need more than just a Session to access them.
What's wrong with recording the
sincefield in Session like I suggested?vishadGoyal commentedon Sep 13, 2021
The data is not already present where the declared_lib_features is currently being built.
Its present in library/core/src/intrinsics.rs
I'm not sure how to access it from where you mentioned.
jyn514 commentedon Sep 13, 2021
@vishadGoyal it should be in the attribute you're currently looking at - see how it's done in
rust/compiler/rustc_passes/src/lib_features.rs
Line 36 in 1cd17ad
The language features are hard-coded into the compiler, but that doesn't mean the library features aren't available, they just have to be determined at runtime.
vishadGoyal commentedon Sep 13, 2021
I logged the attribute being looked at
I couldn't find any stability attribute in it or it's meta. The output when I printed the meta of this attr was
jyn514 commentedon Sep 13, 2021
@vishadGoyal you're looking at the
#[feature(...)]attribute. You want to look at the#[stable(...)]attribute.Hmm, this may be tricky to do in parsing, since it's in another crate - I wonder if we could delay checking library features until later in the compiler, maybe to the pass where it checks if the feature is already stable? I remember @Mark-Simulacrum saying features were checked early to avoid stabilizing syntax by accident, but that shouldn't be an issue for library features: https://rust-lang.zulipchat.com/#narrow/stream/182449-t-compiler.2Fhelp/topic/Why.20are.20feature.20gates.20checked.20during.20parsing.3F
vishadGoyal commentedon Sep 14, 2021
I'm new to this so can you explain why the treatment can be different for lang features and lib features?
jyn514 commentedon Sep 14, 2021
Library features can't affect the syntax passed to proc macros; language features can.
vishadGoyal commentedon Sep 16, 2021
So, what should be the ideal behavior in this scenario?
If
#![feature]is used with only lib features and not with a language feature, should the compiler still throw an error or just a warning forunnecessary_stable_feature_lint?Or should we always throw an error if
#![feature]is used in beta or stable channels?jyn514 commentedon Sep 16, 2021
@vishadGoyal you should still give a hard error, but it should be later in the compiler after the TyCtxt has been constructed, not during parsing.
vishadGoyal commentedon Sep 16, 2021
I've made the suggested changes. #89012
Rollup merge of rust-lang#89012 - vishadGoyal:issue-88802-fix, r=jyn514
jyn514 commentedon Sep 23, 2021
Fixed in #89012.