Nightly features in a parent Cargo.toml causes build in unrelated sub-crate to fail when building with beta or stable cargo

[TheZoq2]

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:

$ /tmp/root_crate/subcrate ➔ cargo build                                                                                                                                                                                                                                     (master|…)wraith
error: failed to parse manifest at `/tmp/root_crate/Cargo.toml`

Caused by:
  the cargo feature `profile-overrides` requires a nightly version of Cargo, but this is the `beta` channel

Running with RUST_LOG=trace also produces this:

$ /tmp/root_crate/subcrate ➔ RUST_LOG=trace ca b                                                                                                                                                                                                                      
[2019-02-09T16:23:38Z TRACE cargo::util::toml] read_manifest; path=/tmp/root_crate/subcrate/Cargo.toml; source-id=/tmp/root_crate/subcrate
[2019-02-09T16:23:38Z DEBUG cargo::core::workspace] find_root - trying /tmp/root_crate/Cargo.toml
[2019-02-09T16:23:38Z TRACE cargo::util::toml] read_manifest; path=/tmp/root_crate/Cargo.toml; source-id=/tmp/root_crate
[2019-02-09T16:23:38Z TRACE cargo::util::errors] error: the cargo feature `profile-overrides` requires a nightly version of Cargo, but this is the `beta` channel
[2019-02-09T16:23:38Z TRACE cargo::util::errors]        context: failed to parse manifest at `/tmp/root_crate/Cargo.toml`
[2019-02-09T16:23:38Z DEBUG cargo] exit_with_error; err=CliError { error: Some(ErrorMessage { msg: "the cargo feature `profile-overrides` requires a nightly version of Cargo, but this is the `beta` channel" }

failed to parse manifest at `/tmp/root_crate/Cargo.toml`), unknown: false, exit_code: 101 }
error: failed to parse manifest at `/tmp/root_crate/Cargo.toml`

Caused by:
  the cargo feature `profile-overrides` requires a nightly version of Cargo, but this is the `beta` channel

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

1. Create a new crate cargo init root_crate
2. Create another crate inside the sub-crate cd root_crate && cargo init sub_crate
3. Add cargo-features = ["profile-overrides"] to the Cargo.toml in root_crate
4. Try building the sub-crate using beta or stable 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 not

Notes

This happens with both cargo 1.33.0-beta (9b5d4b755 2019-01-15) and cargo 1.31.0 (339d9f9c8 2018-11-16)

[dwijnand]

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?

[TheZoq2]

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 🤔.

[epage]

#6707 is about general errors in a parent manifest which has problems with whether we can tell if it is intended to be a workspace or not.

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.