Re-land early syntax feature gating (was: Some features can no longer be controlled by conditional compilation)

[RalfJung]

#66004 fixed the original issue; now this tracks re-landing those checks (possibly after some transition period).

Original issue

At https://github.com/RalfJung/miri-test-libstd/, I have set things up such that one can run the libcore and liballoc test suite against Miri. The basic idea is to have a Cargo.toml file like this (very close to the normal one for libcore):

[package]
authors = ["The Rust Project Developers"]
name = "core_miri_test"
version = "0.0.0"
autotests = false
autobenches = false
edition = "2018"

[lib]
name = "core_miri_test"
path = "../libcore/lib.rs"
test = false
bench = false

[[test]]
name = "coretests"
path = "../libcore/tests/lib.rs"

[dev-dependencies]
rand = "0.7"

Then I make ../libcore a symlink to the actual libcore sources, cd into the dir with the above Cargo.toml, and run cargo miri test. This worked fine until recently (until nightly-2019-10-17, to be precise).

But since then something broke, and now I get lots of build failures:

error[E0658]: associated type bounds are unstable
   --> core_miri_test/../libcore/pin.rs:445:15
    |
445 | impl<P: Deref<Target: Unpin>> Pin<P> {
    |               ^^^^^^^^^^^^^
    |
    = note: for more information, see https://github.com/rust-lang/rust/issues/52662
    = help: add `#![feature(associated_type_bounds)]` to the crate attributes to enable

error[E0658]: associated type bounds are unstable
   --> core_miri_test/../libcore/pin.rs:754:18
    |
754 | impl<P: DerefMut<Target: Unpin>> DerefMut for Pin<P> {
    |                  ^^^^^^^^^^^^^
    |
    = note: for more information, see https://github.com/rust-lang/rust/issues/52662
    = help: add `#![feature(associated_type_bounds)]` to the crate attributes to enable

I tried adding these feature gates to every crate root I could think of (the lib.rs of both libcore and its test crate), but the errors are sticking. Unfortunately the error doesn't tell me which file it thinks is the crate root.

Any idea what this could be caused by? Until this is fixed, we won't have Miri coverage of the libcore and liballoc test suite.

[RalfJung]

The failing command seems to be

/home/r/.cargo/bin/cargo-miri rustc --edition=2018 --crate-name core_miri_test core_miri_test/../libcore/lib.rs --error-format=json --json=diagnostic-rendered-ansi --emit=dep-info,link -C debuginfo=2 cargo-miri-marker-begin cargo-miri-marker-end --test -C metadata=c5be0bd0faaf3ad2 -C extra-filename=-c5be0bd0faaf3ad2 --out-dir /home/r/src/rust/miri-test-libstd/target/debug/deps -C incremental=/home/r/src/rust/miri-test-libstd/target/debug/incremental -L dependency=/home/r/src/rust/miri-test-libstd/target/debug/deps --extern rand=/home/r/src/rust/miri-test-libstd/target/debug/deps/librand-bd1cec56ecfccb49.rlib

So this is where it builds libcore itself, not the test crate.

[RalfJung]

I can get the same errors without Miri being involved by running rustc +nightly lib.rs --test --edition 2018 in src/libcore.

Cc @alexcrichton and @eddyb who helped me to set this up at the all-hands early this year

[eddyb]

cc @Centril maybe there is something weird going on with the feature-gating here.

[Centril]

The only relevant information I can contribute here is that feature gating for this is done pre-expansion today.

[RalfJung]

libcore has a #![cfg(not(test))], so the crate really should be empty. I guess "pre-expansion" means stuff happens before the cfg is applied?

But then, why does it see the uses of this feature, but does not see the feature flag?

[RalfJung]

@Centril here's a minimal example:

#![cfg(foobar)]

#![feature(decl_macro)]
pub macro Default($item:item) { }

This gets rejected, which IMO is a bug.

[eddyb]

cc @petrochenkov

[RalfJung]

Here's another variant:

#![cfg_attr(nightly, feature(decl_macro))]

#[cfg(nightly)]
pub macro Default($item:item) { }

This shows that only conditionally using this feature is broken right now.

[RalfJung]

Regression likely introduced by #65742.

[RalfJung]

Nominating for compiler team discussion. IMO this regression should be fixed or the PR reverted.