Cargo sometimes doesn't ungate crate features

[CAD97]

D:\Christopher\Documents\Code\Rust\rust-unic\unic\char\range>cd ../../..

D:\Christopher\Documents\Code\Rust\rust-unic>cargo.exe +nightly check --all-features --package=unic-char-range
    Finished dev [unoptimized + debuginfo] target(s) in 0.0 secs

D:\Christopher\Documents\Code\Rust\rust-unic>cd unic/char/range

D:\Christopher\Documents\Code\Rust\rust-unic\unic\char\range>cargo.exe +nightly check --all-features --package=unic-char-range
   Compiling unic-char-range v0.7.0 (file:///D:/Christopher/Documents/Code/Rust/rust-unic/unic/char/range)
error: 
 --> unic\char\range\src\par_iter.rs:8:9
  |
8 |         compile_error!("")
  |         ^^^^^^^^^^^^^^^^^^

error: aborting due to previous error

error: Could not compile `unic-char-range`.

To learn more, run the command again with --verbose.

D:\Christopher\Documents\Code\Rust\rust-unic\unic\char\range>cargo.exe +nightly check --package=unic-char-range
    Finished dev [unoptimized + debuginfo] target(s) in 0.0 secs

I was trying to add optional rayon ParIter support to unic-char-range, and ran into this situation. Adding the optional dependency, a #[cfg(feature = "rayon")] mod par_iter; to lib.rs, and a compile_error! to the new file led to this interesting situation.

Annoyingly, I haven't been able to reproduce this behavior in a smaller setup. You can check out Unic with the code reproducing this error, but I attempted to reproduce what I thought might be triggering it -- a root workspace with a different feature set from the end package -- but it didn't.

[matklad]

@CAD97 currently, the --all-features flag applies to the package in the working directory, and not to the --package package, and this is indeed as bizarre as it sounds :-) Amusingly, I've just fixed this bug in #5353, but, because it is a pretty drastic change in the behavior, it requires an opt-in for now. So looks like if you add -Z package-features to the command line, the behavior would be consistent?

Am I correct that compile_error!("") is, in fact, the behavior you would expect in both cases?

[CAD97]

Yes, -Z package-features is the desired behavior. The compile_error! was just a very easy way to see whether the feature got enabled. I'll run Unic's suite with -Z package-features and report to the internals thread when it works as desired.

In the mean time until -Z package-features becomes default, it might make sense to warn on unknown features (especially in conjunction with --package). The case this hurts the most has got to be in a virtual workspace where the root doesn't have any features to begin with.