In 1.11 beta, #![cfg] does not mask #![feature]

[DanielKeep]

It looks like rustc is checking feature attributes before processing cfg attributes. If so, this is a problem, because it looks like this makes it impossible to write code that optionally uses unstable features.

In the example below, the 1.10 compiler correctly ignores the test involving unstable features, but beta does not. In my specific case, this means my CI testing on beta for newtype_derive is unavoidably failing.

1.12 nightly complaining about unused features is probably the same issue.

---

Cargo.toml:

[package]
authors = ["Anonymous"]
name = "example"
version = "0.1.0"

[[test]]
name = "dummy"
path = "dummy.rs"

[features]
enable-unstable = []

lib.rs:

/* empty */

dummy.rs:

#![cfg(feature="enable-unstable")]
#![feature(iter_arith_traits)]

#[test]
fn dummy() {}

---

> multirust run stable rustc -vV; multirust run beta rustc -vV; multirust run nightly rustc -vV
rustc 1.10.0 (cfcb716cf 2016-07-03)
binary: rustc
commit-hash: cfcb716cf0961a7e3a4eceac828d94805cf8140b
commit-date: 2016-07-03
host: i686-pc-windows-gnu
release: 1.10.0
rustc 1.11.0-beta.1 (8dc253bcf 2016-07-05)
binary: rustc
commit-hash: 8dc253bcf3a565deb575108992b9f2e7d985aa17
commit-date: 2016-07-05
host: i686-pc-windows-gnu
release: 1.11.0-beta.1
rustc 1.12.0-nightly (7ad125c4e 2016-07-11)
binary: rustc
commit-hash: 7ad125c4eb3d620c12a868dbe77180f1a133021b
commit-date: 2016-07-11
host: i686-pc-windows-gnu
release: 1.12.0-nightly
> multirust run stable cargo test --no-default-features --features=""
   Compiling example v0.1.0 (file:///F:/Programming/Rust/sandbox/issues/beta-cfg-feature)
     Running target\debug\dummy-ae1963bd31fb7672.exe

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured

> multirust run stable cargo test --no-default-features --features="enable-unstable"
   Compiling example v0.1.0 (file:///F:/Programming/Rust/sandbox/issues/beta-cfg-feature)
dummy.rs:2:1: 2:31 error: #[feature] may not be used on the stable release channel
dummy.rs:2 #![feature(iter_arith_traits)]
           ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
error: aborting due to previous error
error: Could not compile `example`.

To learn more, run the command again with --verbose.
> multirust run beta cargo test --no-default-features --features=""
   Compiling example v0.1.0 (file:///F:/Programming/Rust/sandbox/issues/beta-cfg-feature)
dummy.rs:2:1: 2:31 error: #[feature] may not be used on the beta release channel [E0554]
dummy.rs:2 #![feature(iter_arith_traits)]
           ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
error: aborting due to previous error
error: Could not compile `example`.

To learn more, run the command again with --verbose.
> multirust run beta cargo test --no-default-features --features="enable-unstable"
   Compiling example v0.1.0 (file:///F:/Programming/Rust/sandbox/issues/beta-cfg-feature)
dummy.rs:2:1: 2:31 error: #[feature] may not be used on the beta release channel [E0554]
dummy.rs:2 #![feature(iter_arith_traits)]
           ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
error: aborting due to previous error
error: Could not compile `example`.

To learn more, run the command again with --verbose.
> multirust run nightly cargo test --no-default-features --features=""
   Compiling example v0.1.0 (file:///F:/Programming/Rust/sandbox/issues/beta-cfg-feature)
dummy.rs:2:12: 2:29 warning: unused or unknown feature, #[warn(unused_features)] on by default
dummy.rs:2 #![feature(iter_arith_traits)]
                      ^~~~~~~~~~~~~~~~~
     Running target\debug\dummy-ae1963bd31fb7672.exe

running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured

> multirust run nightly cargo test --no-default-features --features="enable-unstable"
   Compiling example v0.1.0 (file:///F:/Programming/Rust/sandbox/issues/beta-cfg-feature)
dummy.rs:2:12: 2:29 warning: unused or unknown feature, #[warn(unused_features)] on by default
dummy.rs:2 #![feature(iter_arith_traits)]
                      ^~~~~~~~~~~~~~~~~
     Running target\debug\dummy-ae1963bd31fb7672.exe

running 1 test
test dummy ... ok

test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured

[nagisa]

it looks like this makes it impossible to write code that optionally uses unstable features.

You should be using cfg_attr in the first place. I don’t remember anything being said about evaluation order of separate attributes.

[DanielKeep]

You should be using cfg_attr in the first place.

On the one hand, good point. That does solve the issue; I think I didn't try that because I didn't expect it to behave any differently. I retract my "impossible" accusation.

On the other hand, this is an observable change in behaviour.

[pnkfelix]

Its not clear to me how #![cfg(...)] at the crate level should even work, or what it means.

In other words: I would normally be sympathetic to the idea that this is a regression, but I am currently wondering if this was just a latent language bug that the code worked before at all.

[retep998]

Its not clear to me how #![cfg(...)] at the crate level should even work, or what it means.

It simply means the entire contents of the crate should be ignored. I use it in winapi for non-windows platforms.

[nrc]

cc @jseyfried did you make this change? I seem to remember you did it deliberately and for good reason, but I don't remember that reason.

[pnkfelix]

It simply means the entire contents of the crate should be ignored.

I find this semantics odd. Since the crate is still present (just empty), while if this #![cfg(...)] attribute were to appear within a module, that would cause the mod item itself to disappear (right?), rather than just being an empty module.

I'm willing to accept that this is merely a small discontinuity in the semantic of #![cfg(...)] when it appears at the root of a crate, but we should make sure that is documented somewhere in that case.

[jseyfried]

@nrc I unintentionally made this change in #34272 -- fixed in #34969.