Currently, Cargo will always set `$CARGO` to point to what it detects
its own path to be (using `std::env::current_exe`). Unfortunately, this
runs into trouble when Cargo is used as a library, or when `current_exe`
is not actually the binary itself (e.g., when invoked through Valgrind
or `ld.so`), since `$CARGO` will not point at something that can be used
as `cargo`. This, in turn, means that users can't currently rely on
`$CARGO` to do the right thing, and will sometimes have to invoke
`cargo` directly from `$PATH` instead, which may not reflect the `cargo`
that's currently in use.
This patch makes Cargo re-use the existing value of `$CARGO` if it's
already set in the environment. For Cargo subcommands, this will mean
that the initial invocation of `cargo` in `cargo foo` will set `$CARGO`,
and then Cargo-as-a-library inside of `cargo-foo` will inherit that
(correct) value instead of overwriting it with the incorrect value
`cargo-foo`. For other execution environments that do not have `cargo`
in their call stack, it gives them the opportunity to set a working
value for `$CARGO`.
One note about the implementation of this is that the test suite now
needs to override `$CARGO` explicitly so that the _user's_ `$CARGO` does
not interfere with the contents of the tests. It _could_ remove `$CARGO`
instead, but overriding it seemed less error-prone.
Fixes#10119.
Fixes#10113.
When working on clap v4, it appeared that `last` and `trailing_var_arg`
are mutually exclusive, so I called that out in the debug asserts in
clap-rs/clap#4187. Unfortunately, I didn't document my research on this
as my focus was elsewhere.
When updating cargo to use clap v4 in #11159, I found `last` and
`trailing_var_arg` were used together. I figured this was what I was
trying to catch with above and I went off of my intuitive sense of these
commands and assumed `trailing_var_arg` was intended, not knowing about
the `testname` positional that is mostly just a forward to `libtest`,
there for documentation purposes, except for a small optimization.
So it looks like we just need the `last` call and not the
`trailing_var_arg` call.
This restores us to behavior from 531ce1321 which is what I originally
wrote the tests against.
This allows consumers of the json messages to avoid guessing where
exactly the package root is. Having access to the package root is
difficult by virtue of requiring logic to guess its location by e.g.
walking filesystem from the source file.
This guessing logic becomes further complicated in presence of
workspaces and nigh impossible to implement correctly in instances where
artifacts end up produced from paths above the package root (e.g.
`../foo.rs`).
Since Cargo has access to this data in the first place, there doesn't
seem to be much reason to force consumers to invent their own, possibly
flawed, logic.
Make it more clear which module is being tested when running cargo test
I recently asked in zulip if this is a good idea, as I find it hard to find the module thats being tested from the complex path with the hash.
Output of `cargo test`:
```
2021-02-21 13:29:33 I > ~/repos/cargo/target/debug/cargo test
Finished test [unoptimized + debuginfo] target(s) in 0.42s
Running unittests (target/debug/deps/test_tests-759130ea61f71571)
running 1 test
test tests::unit_test ... ok
test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in
0.00s
Running tests2/lib.rs (target/debug/deps/integration_tests-6b7f9fcd1721f083)
running 2 tests
test tests2_lib ... ok
test second_test::tests2_second ... ok
test result: ok. 2 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in
0.00s
Running tests/lib.rs (target/debug/deps/lib-d2be6d29597c2790)
running 2 tests
test second_test::tests_i_am_run_twice ... ok
test tests_lib ... ok
test result: ok. 2 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in
0.00s
...
```
By doing so, rustdoc will also emit workspace-relative filenames for the doctests.
This was first landed in #8954 but later backed out in #8996 because it changed the CWD of rustdoc test invocations.
The second try relies on the new `--test-run-directory` rustdoc option which was added in https://github.com/rust-lang/rust/pull/81264 to explicitly control the rustdoc test cwd.
fixes#8993
To avoid regressions to the test runtime directory, this asserts that
all test types (unit, integration, doctest) are executed in the crate
(manifest) directory, no matter where that crate is in relation to the
workspace root.
See #8992 / #8993
Publish target's "doc" setting when emitting metadata
Prior to this commit `cargo metadata` would not emit the value of a
target's "doc" setting, used by `cargo doc` to determine whether
documentation should be generated. However, this information is useful
for machine programs interested in such targets, and the information is
already made available on the internal representation of a target, so
this commit just exposes that during target serialization for emit.
cf https://github.com/deadlinks/cargo-deadlinks/issues/99
Prior to this commit `cargo metadata` would not emit the value of a
target's "doc" setting, used by `cargo doc` to determine whether
documentation should be generated. However, this information is useful
for machine programs interested in such targets, and the information is
already made available on the internal representation of a target, so
this commit just exposes that during target serialization for emit.
cf https://github.com/deadlinks/cargo-deadlinks/issues/99
Use associated constants directly on primitive types instead of modules
This PR is in no way critical. It's more of a code cleanup. It comes as a result of me making https://github.com/rust-lang/rust/pull/70857 and search-and-replacing all usage of the soft-deprecated ways of reaching primitive type constants.
It makes the code slightly shorter, that's basically it. And showcases the recommended way of reaching these consts on new code :)
Recently added in rust-lang/rust#64158 the `-Z panic-abort-tests` flag
to the compiler itself will activate a mode in the `test` crate which
enables running tests even if they're compiled with `panic=abort`. It
effectively runs a test-per-process.
This commit brings the same support to Cargo, adding a `-Z
panic-abort-tests` flag to Cargo which allows building tests in
`panic=abort` mode. While I wanted to be sure to add support for this in
Cargo before we stabilize the flag in `rustc`, I don't actually know how
we're going to stabilize this here. Today Cargo will automatically
switch test targets to `panic=unwind`, and so if we actually were to
stabilize this flag then this configuration would break:
[profile.dev]
panic = 'abort'
In that case tests would be compiled with `panic=unwind` (due to how
profiles work today) which would clash with crates also being compiled
with `panic=abort`. I'm hopeful though that we can perhaps either figure
out a solution for this and maybe even integrate it with the ongoing
profiles work.
