Open TheZoq2 opened 5 years ago
How would detecting if the parent package is a workspace change the fact that cargo features change cargo's behaviour?
Why do you consider this a bug?
Why do you consider this a bug?
Because it broke my, admittedly weird, use case where one crate failed to build because of the workspace feature which I didn't use. I suppose this might also be a case of https://xkcd.com/1172/.
Still, it took a lot of debugging to figure out why a seemingly unrelated Cargo.toml prevented my crate from compiling. If nothing else, a warning would be nice.
How would detecting if the parent package is a workspace change the fact that cargo features change cargo's behaviour?
Perhaps I worded that weirdly. What i'm suggesting is that if you try to build a crate on stable and workspace lookup finds a broken Cargo.toml, then it should ignore it if there is no indication of it being a workspace toml.
Though I suppose that could cause other issues with malformed workspace tomls :thinking:.
If we could split the parsing so extra validation, like checking cargo_features
, is done outside of the "is workspace" check, then that would bypass this problem (and help with a subset of problems from #6706). Granted, this all depends on if validation is done within serde or after it which can easily shift from release to release.
Problem
If one crate that uses nightly-only cargo features has a subdirectory containing another crate, then that crate also requires a nightly cargo version to build in order to not fail when looking for workspaces.
If running cargo build in the subfolder with a stable or beta version of cargo, the following error is produced:
Running with
RUST_LOG=trace
also produces this:Which seems to indicate that the workspace finder tries to parse the toml, but fails because of the unknown feature thing.
Removing the cargo feature and building again fixes the issue.
Steps
cargo init root_crate
cd root_crate && cargo init sub_crate
cargo-features = ["profile-overrides"]
to theCargo.toml
inroot_crate
cargo +stable build
Possible Solution(s)
This seems like a pretty difficult problem to solve assuming
cargo_features
presumably can change the behaviour of cargo. However, it would be nice if it could try to detect wether a Cargo.toml containing unstable features is a workspace or notNotes
This happens with both
cargo 1.33.0-beta (9b5d4b755 2019-01-15)
andcargo 1.31.0 (339d9f9c8 2018-11-16)