Honor runner configuration for sub-crates in workspaces

[d-e-s-o]

Problem

When I have a workspace and one of the crates defines a custom test runner, this test runner is not used when running cargo test from the workspace root, only when executing it from the sub-crate itself. E.g.,

mkdir workspace
cd workspace
cargo init --lib crate1
cargo init --lib crate2
mkdir crate2/.cargo
cat <<EOF > crate2/.cargo/config
[target.x86_64-unknown-linux-gnu]
runner = "false"
EOF
cat <<EOF > Cargo.toml
[workspace]
members = [
  "crate1",
  "crate2",
]
EOF

$ cargo test
>   Compiling crate2 v0.1.0 (workspace/crate2)
>   Compiling crate1 v0.1.0 (workspace/crate1)
>    Finished test [unoptimized + debuginfo] target(s) in 0.23s
>     Running unittests src/lib.rs (workspace/target/debug/deps/crate1-17df813c4096d5b4)
>
>running 1 test
>test tests::it_works ... ok
>
>test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s
>
>     Running unittests src/lib.rs (workspace/target/debug/deps/crate2-adadd9a2fd7f0375)
>
>running 1 test
>test tests::it_works ... ok
>
>test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s
>
>   Doc-tests crate1
>
>running 0 tests
>
>test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s
>
>   Doc-tests crate2
>
>running 0 tests
>
>test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

$ cd crate2/
$ cargo test
>     Finished test [unoptimized + debuginfo] target(s) in 0.00s
>      Running unittests src/lib.rs (workspace/target/debug/deps/crate2-adadd9a2fd7f0375)
> error: test failed, to rerun pass `--lib`
>
> Caused by:
>   process didn't exit successfully: `false workspace/target/debug/deps/crate2-adadd9a2fd7f0375` (exit status: 1)

In some weird way this seems to be yet another instance of #8870 (which I am still battling...)

Proposed Solution

Please: honor the logical configuration for the respective crate for which tests are run.

In the example above, I expect cargo test to fail for crate2 even if run from the workspace root.

Notes

I classified this issue as a feature request because as per #8870 it can probably be argued that this is "by design" (and not a bug). Yet, this design is most certainly questionable, in my opinion.

[ehuss]

Thanks for the report! It is known that it can be confusing that cargo uses the current directory to determine which configuration files to load. Closing as a duplicate of #2930, #9769, and #10098 (and possibly https://internals.rust-lang.org/t/proposal-move-some-cargo-config-settings-to-cargo-toml/13336).

[epage]

To add, .cargo/config files are environment configuration, rather than package configuration, and are dependent on your CWD and not the directory of the package being run/tested. Hence, we are identifying config that is really package related and moving it to Cargo.toml (the linked internals thread). rust-lang/rfcs#3389 is an example of that.

[d-e-s-o]

Thanks for the pointers. I am happy to hear that this is being recognized as an issue and looked at!