Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
stepancheg opened this issue May 14, 2023 · 4 comments
Closed
Labels
C-bug Category: bug S-triage Status: This issue is waiting on initial triage.

Comments

@stepancheg
Copy link
Contributor

stepancheg commented May 14, 2023

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]
@stepancheg stepancheg added C-bug Category: bug S-triage Status: This issue is waiting on initial triage. labels May 14, 2023
@epage
Copy link
Contributor

epage commented May 15, 2023

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
Copy link
Contributor Author

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
Copy link
Contributor

epage commented May 15, 2023

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
Copy link
Contributor

epage commented May 17, 2023

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.

@epage epage closed this as not planned Won't fix, can't repro, duplicate, stale May 17, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-bug Category: bug S-triage Status: This issue is waiting on initial triage.
Projects
None yet
Development

No branches or pull requests

2 participants