Even with resolver=2 features are unified when starting from project root

[stepancheg]

Problem

Different features of the crate a used depending on how what is the directory we start compilation from.

Steps

Full code is in this repository https://github.com/stepancheg/cargo-features-bug

What it has:

• three crates: a, b, common
• crate common defines two features x and y and has a function which prints the features
• crate a depends on common with feature x
• crate b depends on common with feature y
• crate a has a binary which prints features of common
• there is not package in the workspace root

Steps

• clone the repository
• cargo run --bin a from the repository root:

feature = "x"
feature = "y"

• but cargo run -p a from the repository root:

feature = "x"

• and from directory a, cargo run -p a or cargo run --bin a

feature = "x"

Which means feature y of crate common is activated depending on what is the directory we start compilation from.

I don't know if that's expected behavior but it is very unintuitive.

Cargo tree

Additionally, cargo tree does not help to debug it. From the repository root if I do cargo tree -p a -e features (which is what I do when I see misbehaving cargo run --bin a):

a v0.1.0 (/Users/nga/devel/cargo-features-bug/a)
├── common feature "default"
│   └── common v0.1.0 (/Users/nga/devel/cargo-features-bug/common)
└── common feature "x"
    └── common v0.1.0 (/Users/nga/devel/cargo-features-bug/common)

It does not give any hint that cargo run --bin a would enable feature y.

There's no option cargo tree --bin a.

Possible Solution(s)

Do not use command without explicit -p flags from the repository root.

Version

cargo 1.68.0-nightly (d992ab4e9 2023-01-10)
release: 1.68.0-nightly
commit-hash: d992ab4e9034930e7809749f04077045af8f4d79
commit-date: 2023-01-10
host: aarch64-apple-darwin
libgit2: 1.5.0 (sys:0.16.0 vendored)
libcurl: 7.87.0 (sys:0.4.59+curl-7.86.0 system ssl:(SecureTransport) LibreSSL/3.3.6)
os: Mac OS 13.3.1 [64-bit]

[epage]

Which means feature y of crate common is activated depending on what is the directory we start compilation from.

Unless I'm misreading something, that is an incomplete statement. What matters is what package is selected and not just the directory

• in the root the default selection is all
• in a/ the default selection is a
• with -p a, a is explicitly selected

The features are then unified across all selected packages. This is behaving as intended and resolver=2 was not intended to change this behavior.

From the repository root if I do cargo tree -p a -e features (which is what I do when I see misbehaving cargo run --bin a):
...
It does not give any hint that cargo run --bin a would enable feature y.

Sounds like cargo tree is correctly reporting what happens when you do cargo run -p a and it shouldn't be giving you a hint for cargo run --bin a .

There's no option cargo tree --bin a.

That would just be cargo tree. --bin does not do package selection but runs the specified target among the selected packages.

Do not use command without explicit -p flags from the repository root.

I'm not quite sure what you mean here. Are you suggesting we error instead? Unfortunately, that is not likely to happen as that would be a breaking change.

[stepancheg]

Are you suggesting we error instead? Unfortunately, that is not likely to happen as that would be a breaking change.

If there was a warning, that would have saved me an hour of debugging. Something like this:

building crate common with features x and y instead of just x because package a is not selected explicitly, so all workspace features are used. Consider re-running the command with a flag -p a.

[epage]

A warning would only help a fraction of users and would likely not be able to report the difference in features.

We are also very judicious in producing warnings because there is no way to control them. With #12115, we might start introducing more cargo warnings.

[epage]

Also, it looks like this is a duplicate of #8157, closing in favor of it. If I missed an aspect that is different, let us kow.