Resolution of dependencies should not be affected by the dependencies of procedural-macro-library.

[andylokandy]

Currently, the dependencies of procedural-macro-library would change the resolution of normal dependency of root package, which accidentally broke some crates and made them unusable in no_std environment.

For example:

Case A:

[package]
name = "demo"
version = "0.1.0"

[dependencies]
num-traits = { version = "0.2", default-features = false} 

// lib.rs

#![no_std]

extern crate num_traits;

> rustup target add thumbv7m-none-eabi
> cargo build --target thumbv7m-none-eabi
    Finished dev [unoptimized + debuginfo] target(s) in 0.02s

It compiled as expected; the default features is turned off, so that the std feature of num-traits is also removed.

Case B:

[package]
name = "demo"
version = "0.1.0"

[dependencies]
num-derive = "0.2"

// lib.rs

#![no_std]

#[macro_use]
extern crate num_derive;

PS K:\Code\Playground\fail> cargo build --target thumbv7m-none-eabi
   Compiling demo v0.1.0 (file:///K:/Code/Playground/fail)
   (...unused_imports warning...)

    Finished dev [unoptimized + debuginfo] target(s) in 0.66s

It also compiled as expected, though the num_derive depends on non-no-std libraries, like syn, quote and the num_traits with std feature. It's because num_derive is proc-macro-library and it's not going to be linked, which means the num_derive should only work at compile time. Thus, it is not constrained by no_std environment. In other words, the no_std environment should not be affected by proc-macro and no_link crates as well.

Case C:

[package]
name = "demo"
version = "0.1.0"

[dependencies]
num-derive = "0.2"
num-traits = { version = "0.2", default-features = false} 

// lib.rs

#![no_std]

#[macro_use]
extern crate num_derive;
extern crate num_traits;

> cargo build --target thumbv7m-none-eabi
   Compiling num-traits v0.2.5
error[E0463]: can't find crate for `std`====================>           ] 9/11: num-traits
  --> C:\Users\Andy\.cargo\registry\src\github.com-1ecc6299db9ec823\num-traits-0.2.5\src\lib.rs:23:1
   |
23 | extern crate std;
   | ^^^^^^^^^^^^^^^^^ can't find crate
   |
   = note: the `thumbv7m-none-eabi` target may not be installed

error: aborting due to previous error

For more information about this error, try `rustc --explain E0463`.
error: Could not compile `num-traits`.

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

In this case, rustc complians that the num-traits with std feature is used in no_std environment. Which is weird because we have required Cargo to remove it! If we build it by verbose, we can see the std feature is passed to rustc!

I guess it is because the resolution of proc-marco-library, num-derive, changed the feature resolution of num-traits in root. This problem may also arise in no_link library.

[Eh2406]

Thanks for letting us know about this problem. I agree that it is a problem and one that needs to be fixed. The current discussion of how is at #5730. Unfortunately it is a rather big braking change to how features were originally designed to work, so it will take some time to figure out.

But let's have the conversation in #5730 and mark this as a duplicate.