rust-lang / cargo

The Rust package manager
https://doc.rust-lang.org/cargo
Apache License 2.0
12.66k stars 2.41k forks source link

unstable features breaks unrelated sub-project #6015

Open xd009642 opened 6 years ago

xd009642 commented 6 years ago

So for my project cargo-tarpaulin I've had to switch to the nightly publish-lockfile to get past an issue some users have had. As tarpaulin is meant to run on other peoples crates in my tests folder I have a folder called data with some sub-projects to run tarpaulin on to make sure it works.

However, now when I go into subproject and run cargo test on stable it gives me an error because of the present of publish-lockfile in the project root. But as these test projects aren't used to by tarpaulin and don't pull in tarpaulin as a library and my current working directory is their root I don't think they should take into account any parent folders.

Here is a link to the project https://github.com/xd009642/tarpaulin/tree/master/tests/data/simple_project

The error:

[xd009642@localhost simple_project]$ cargo test
error: failed to parse manifest at `/home/xd009642/code/rust/tarpaulin/Cargo.toml`

Caused by:
  the cargo feature `publish-lockfile` requires a nightly version of Cargo, but this is the `stable` channel

And the Cargo.toml in the directory cargo test was ran in:

[package]
name = "simple_project"
version = "0.1.0"
authors = ["Daniel McKenna <danielmckenna93@gmail.com>"]

[dependencies]

Moving the folder simple project to a folder above tarpaulins root fixes this but obviously I'd prefer a workaround or some fix for this as it also affects tarpaulin (I use cargo as a library to build the project tests and handle features/packages).

alexcrichton commented 6 years ago

A curious bug! This can sometimes happen I believe if the crate thinks it's in a workspace, and Cargo may be a little too eagerly reporting errors there instead of ignoring manifests it can't parse due to this error.

If you add [workspace] to simple_project does it fix the issue?

xd009642 commented 6 years ago

Adding [workspace] solved it, so it's up to you if it should be closed or not :+1:. Dunno if there's another issue for this etc.

EDIT: If you saw the next paragraph about an error I saw the error was a user one so ignore it :

alexcrichton commented 6 years ago

Ah ok, great! In that case I think this seems ok to fix in Cargo, basically ignoring manifests that enable features when looking for a workspace root