Cargo confused about broken Cargo.toml in $HOME

[vorner]

Problem

Sometimes, I just temporarily copy or move files to my $HOME (during a rebase or something). I did that with Cargo.toml today.

If I try to run cargo build in any project, it then tries to load the Cargo.toml in the $HOME too ‒ which is likely unrelated to the current project and is likely broken (because $HOME/src does not exist, so it can't decide what to compile there). That is quite confusing behaviour.

$ cargo new stuff
     Created binary (application) `stuff` package
$ cd stuff/
$ cargo build
   Compiling stuff v0.1.0 (/home/vorner/stuff)
    Finished dev [unoptimized + debuginfo] target(s) in 0.15s
$ cp Cargo.toml ~
$ cargo build
error: failed to parse manifest at `/home/vorner/Cargo.toml`

Caused by:
  no targets specified in the manifest
  either src/lib.rs, src/main.rs, a [lib] section, or [[bin]] section must be present

Notes

Output of cargo version:

cargo 1.34.0-nightly (5c6aa46e6 2019-02-22) (but happens with stable too, so I guess it's there for a while)

[lukaslueg]

This is because core::workspace::find_root() first tries to figure out if the current crate is part of a workspace and then falls for the orphaned manifest in $HOME.

There is a legitimate use case for having a ws-manifest in $HOME (e.g. a container image being built) so we can't ignore this case. Maybe find_root() should be modified to identify a manifest as the root if and only if it's an actual workspace-manifest (and ignore it if it's a stray package manifest).

[vorner]

Maybe somehow make the errors from parsing/interpretting that one a soft error or warning? If it doesn't look like toml (or package manifest at all), then warn about its existence, but don't fail. Would that be possible?

[epage]

My concern about a warning is that if the actual workspace had an error in it then that would be silently incorrect at worse and product a lot of unrelated errors at best.

Workaround: add a [workspace] to your manifest to prevent searching for the workspace.

rust-lang/rfcs#3279 will allow some control over finding an implied Cargo.toml or a workspace root.

I have considered the idea of allowing package.workspace = false to opt-out of workspace detection for "cargo script".

[epage]

See also #6646 which is a more specialized version of this problem.