Nightly compiler complains about a disabled nightly feature used in an impl block, but the block is cfg-gated by a disabled feature

[gendx]

I tried this code in the playground (using Rust nightly):

#![allow(unexpected_cfgs)]
#![cfg_attr(
    feature = "nightly",
    feature(associated_const_equality)
)]

pub trait NeedsDrop {
    const NEEDS_DROP: bool;
}

impl<T> NeedsDrop for T {
    const NEEDS_DROP: bool = std::mem::needs_drop::<T>();
}

pub trait Foo {}

#[cfg(feature = "nightly")]
impl<T> Foo for T where T: NeedsDrop<NEEDS_DROP = true> {}

I expected to see this happen:

• Given that the playground knows no feature called "nightly" (no Cargo.toml defined), the cfg_attr at the beginning doesn't apply i.e. the associated_const_equality feature isn't enabled.
• Additionally, I also expected the impl block at the last line (which depends on associated_const_equality) to be excluded from conditional compilation.

Instead, this happened: the compiler complained that the impl block uses a nightly feature that isn't enabled (rather than ignoring the impl block altogether).

   Compiling playground v0.0.1 (/playground)
error[E0658]: associated const equality is incomplete
  --> src/lib.rs:18:38
   |
18 | impl<T> Foo for T where T: NeedsDrop<NEEDS_DROP = true> {}
   |                                      ^^^^^^^^^^^^^^^^^
   |
   = note: see issue #92827 <https://github.com/rust-lang/rust/issues/92827> for more information
   = help: add `#![feature(associated_const_equality)]` to the crate attributes to enable
   = note: this compiler was built on 2025-05-12; consider upgrading it if it is out of date

For more information about this error, try `rustc --explain E0658`.
error: could not compile `playground` (lib) due to 1 previous error

Meta

Using the nightly compiler in the playground (https://play.rust-lang.org/?version=nightly&mode=debug&edition=2024).

From the error message:

   = note: this compiler was built on 2025-05-12; consider upgrading it if it is out of date

[fmease]

This works exactly as intended: All (modern) syntax feature gates apply pre-expansion. This is to prevent the situation where stable users start depending on crates that actually use experimental syntax features behind a cfg since the removal of or any modifications to the latter would still break stable users which would be incompatible with Rust's stability guarantees.

[fmease]

Consider feature auto_traits (auto trait Trait { … }) for example which uses a legacy post-expansion feature gate: This lead to crates like https://github.com/leptos-rs/leptos and https://github.com/PyO3/pyo3 using auto traits behind a "nightly" feature flag¹ while having tons of stable users! Modifying or removing the syntax of auto traits is no longer an option (at least not a straightforward one that can take effect immediately).

We strictly want to avoid this kind of impasse!

Footnotes

1. Disclaimer: Last time I checked out those crates was in 2023, so I don't know if that's still the case. ↩

[gendx]

Thank you for the explanation! 👍 Does this apply to all unstable features, or only a subset (e.g. those that are "syntax" features vs. those that gate an API in the stdlib)?

I thought it was a common and reasonable pattern to offer additional features/APIs behind a special cfg (such as a feature named nightly) for users who are willing to use a nightly compiler. As you quoted leptos, they have a build.rs script whose only purpose is to detect if the compiler is nightly: https://github.com/leptos-rs/leptos/blob/main/tachys/build.rs.

Having the ability to use unstable feature in crates is IMO a good way to get these features tested in the field, before they get stabilized.

Users using the stable compiler would indeed be broken if they enabled the nightly feature (unless it's combined with a build script as another layer of gating against non-nightly compilers), but that would IMO be an acceptable trade-off and deviation of the stability guarantees, considering that the crate-level #![feature(foo)] would block them anyway.

Of course, nightly users would also eventually be broken when the unstable feature changes or becomes stabilized, but again that's IMO acceptable given that there are no stability guarantees for unstable features.

I assume that the supported way (if anything is supported here) to enable users with a nightly compiler is to publish a foo-nightly crate separately from the stable foo crate, that only works on (the current) nightly compiler?