Tracking issue for migrating all remaining post-expansion feature gates to pre-expansion ones

[fmease]

Tip

If you've arrived here because you encountered a feature gate warning for unstable syntax behind #[cfg(…)], here's how to you can transform your code while keeping the unstable syntax cfg-conditional:

Before (triggers a feature gate warning):

#[cfg(feature = "nightly")] // or a different cfg-condition
impl !Trait for Type {}     // or a different unstable syntax

After (first approach) (idiomatic, doesn't trigger a warning):

macro_rules! generate { ($( $tt:tt )*) => { $( $tt )* } }

#[cfg(feature = "nightly")]
generate! { impl !Send for NotSend {} }

After (second approach) (idiomatic, doesn't trigger a warning):

macro_rules! generate {
    // Of course, you can use macro metavariables to avoid code duplication etc.
    () => { impl !Trait for Type {} }
}

#[cfg(feature = "nightly")]
generate!();

If you'd like to see a more realistic example, head on over to https://github.com/arcnmx/packed-rs/pull/1/changes.

Steps

1. Find the most recent relevant crater runs and manually reaudit affected crates
   • check if at least some crates have been fixed downstream by now
2. Collect all features where the crater run has happened a long time ago & issue a single crater run for all of them at once
3. For all the other ones that also don't emit a pre-expansion warning yet, add warnings immediately (done)
   • no further input from T-compiler/T-lang should be needed since it's already legitimized by MCP 535.

Affected Syntactic Constructs

1. item modifier default (feature specialization or min_specialization for fns only)
   • we potentially want to drop this feature in favor of a different approach...
   • ...so a syntax gate would make it easier to phase out the syntax later on
   • issue a pre-expansion feature gate warning (legitimized by MCP 535)
   • turn the warning into a hard error (needs crater, T-lang FCP)
2. trait impl modifier ! (feature negative_impls)
   • likely to be stabilized in 1–3 years, so a syntax gate isn't super pressing
   • issue a pre-expansion feature gate warning (legitimized by MCP 535)
   • turn the warning into a hard error (needs crater, T-lang FCP)
3. expression try { … } (feature try_blocks)
   • already has a pre-expansion feature gate warning
   • incredibly likely to be stabilized this year...
   • ...so a syntax gate would be counterproductive / harmful (!)
   • turn the warning into a hard error (needs crater, T-lang FCP)
4. pattern box $pat (feature box_patterns)
   • already has a pre-expansion feature gate warning
   • incredibly likely to be replaced with explicit or implicit deref patterns...
   • ...so a syntax gate would make it easier to phase out the syntax later on
   • turn the warning into a hard error (needs crater, T-lang FCP)
5. pattern $patpath { box $ident }, pseudo binding mode (feature box_patterns)
   • incredibly likely to be replaced with explicit or implicit deref patterns...
   • ...so a syntax gate would make it easier to phase out the syntax later on
   • issue a pre-expansion feature gate warning (legitimized by MCP 535)
   • turn the warning into a hard error (needs crater, T-lang FCP)
6. item trait $ident $genericparams = $bounds; (feature trait_alias)
   • already has a pre-expansion feature gate warning
   • turn the warning into a hard error (needs crater, T-lang FCP)
7. trait item modifier auto (feature auto_traits)
   • already has a pre-expansion feature gate warning
   • turn the warning into a hard error (needs crater, T-lang FCP)
8. (not fitting 100%) syntax impl $traitref for .. {} (early version of a now removed predecessor of feature auto_traits)
   • most recent crater run: PR RUST-121072
   • issue a pre-expansion feature gate warning (legitimized by MCP 535, maybe?)
   • reevaluate RUST-121072's crater report & send downstream patches
   • turn the warning into a hard error (needs T-lang FCP, maybe another crater run)
9. item macro $ident$macroparams { $ttstar } (feature decl_macro)
   • already has a pre-expansion feature gate warning
   • turn the warning into a hard error (needs crater, T-lang FCP)
10. (not fitting 100%) predicates $ty = $ty and $ty == $ty (no corresp. feature was ever added (cc RUST-22074, RUST-87471))
    • straight up hard error (crater: 0 regressions, needs T-lang FCP): PR RUST-153513

Pre-History (Incomplete)

• Feature gate 'yield $expr?' pre-expansion #63545
• Pre-expansion gate most of the things #65742
• Re-land early syntax feature gating (was: Some features can no longer be controlled by conditional compilation) #65860
• Partially revert the early feature-gatings added in #65742. #66004
• Re-add most early unstable syntax gates as future-compat lints compiler-team#535
• Reenable disabled early syntax gates as future-incompatibility lints #99935
• Emit feature gate *warning* for auto traits pre-expansion #116393
• Remove special handling of obsolete impl Trait for .. syntax #121072

Implementation History

• Syntactically reject equality predicates #153513
• Emit a pre-expansion feature gate warning for box'ed struct field patterns #154475
• Emit pre-expansion feature gate warnings for negative impls and specialization #154527

Downstream Patches

• Incoming breakage: Use new auto trait syntax arcnmx/packed-rs#1

[fmease]

For why pre-expansion feature gates are superior to post-expansion ones, read my very recent comment: #153513 (comment).

[fmease]

In case anybody is wondering where the supposed future-incompat lint is that's mentioned in MCP rust-lang/compiler-team#535 and enabled in PR #99935, it's called unstable_syntax_pre_expansion (see also its entry in the rustc book) but (1) it's not advertised in the diagnostic (2) lint control attrs/flags (allow, warn, deny, forbid, expect) don't work for it (incl. -Dwarnings). I haven't found any reasoning behind that.

Moreover, the diagnostic links to issue #65860 which I have closed in favor of this issue. In any case, it wasn't a proper C-future-incompatibility Category: Future-incompatibility lints C-tracking-issue Category: An issue tracking the progress of sth. like the implementation of an RFC anyway.

I'm currently leaning towards removing that lint entirely (turning the improper lint warning into a proper non-lint warning) (not even keeping a removed entry since it isn't advertised anywhere & can't be controlled) however I do acknowledge that future-incompat lints allow for things like no-warn-in-deps vs. warn-in-deps, so that idea might not work out.

Once all gates have been turned into proper pre-expansion ones / the corresp. features have been stabilized, we can easily remove this hidden semi-functioning lint without any traces.