Emit pre-expansion feature gate warnings for negative impls and specialization#154527
Emit pre-expansion feature gate warnings for negative impls and specialization#154527fmease wants to merge 3 commits intorust-lang:mainfrom
Conversation
rustbot
added
S-waiting-on-review
|
r? @nnethercote rustbot has assigned @nnethercote. Use Why was this reviewer chosen?The reviewer was selected based on:
|
fmease
changed the title
| &self, | ||
| negative_impls, | ||
| span.to(of_trait.trait_ref.path.span), | ||
| "negative trait bounds are not fully implemented; \ |
There was a problem hiding this comment.
negative impls != negative trait bounds (the Trait in impl Trait for () is not a trait bound, it's a trait ref)
tests/ui/auto-traits/ungated-impl.rs
Outdated
There was a problem hiding this comment.
Already covered by tests/ui/traits/negative-impls/feature-gate-negative_impls.rs. Likely a remnant of the time when negative impls and auto traits were part of the same feature, optin_builtin_traits.
| //~^ ERROR auto traits are experimental and possibly buggy | ||
|
|
||
| impl !AutoDummyTrait for DummyStruct {} | ||
| //~^ ERROR negative trait bounds are not fully implemented; use marker types for now |
There was a problem hiding this comment.
A gate test for negative impls doesn't belong in a gate test file for auto traits. Likely a remnant of the time when negative impls and auto traits were part of the same feature, optin_builtin_traits.
| if let Defaultness::Default(span) = defaultness { | ||
| self.psess.gated_spans.gate(sym::min_specialization, span); | ||
| self.psess.gated_spans.ungate_last(sym::specialization, span); | ||
| } |
There was a problem hiding this comment.
The idea is: Enabling feat specialization should imply min_specialization (the latter only supports the specialization of associated functions, not associated constants & types however). That's how the post-expansion feature gate already works (it visits the AST).
For the soft pre-expansion feature gate we basically want the same thing. However, I don't want to pass a param to the item parser that tells it if the item is meant to be free, associated or foreign. Instead, all 3 fn item kinds are now part of min_specialization from a pre-expansion perspective if they're marked default which is absolutely fine (default on free & foreign items gets rejected later on during AST validation).
We ungate specialization here since later in rustc_ast_passes::feature_gate, a span gated behind specialization requires feature(specialization) … which is undesirable for assoc fns ofc. Finally, in AST passes we allow feature(specialization) to unlock spans gated behind specialization and ones behind min_specialization. This leads to the desired semantics.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
4 participants
Follow up to #154475; part of #154045.
This shouldn't need any extra input from T-compiler or T-lang since it's legitimized by MCP 535.
However, I have a feeling that negative impls & specialization behind "
#[cfg(feature = "nightly")]" are more prevalent in the ecosystem compared to e.g., auto traits & box patterns, so these new warnings will probably hit a bunch of users. In any case, it's only a warning for now not an error so e.g., running crater "in deny mode" or nominating for a T-lang meeting discussion would be disproportionate (esp. since T-lang has confirmed in the past that this is a T-compiler matter).