In 12914 we stabilized pkgid spec as unique package identifier for
`cargo metadata`. However, we forgot to make the same change to
JSON message format[^1]. This PR does so.
Note that the `package_id` field in JSON message is not clearly stated
as "opaque", so it might be considered as a breaking change to some extent.
[^1]: https://doc.rust-lang.org/nightly/cargo/reference/external-tools.html#compiler-messages
It confuses people that both `--no-fail-fast` and `--keep-going` exist
on `cargo test` and `cargo bench` but with slightly different behavior.
The intended use cases for `--keep-going` involve build commands like
`build`/`check`/`clippy` but never `test`/`bench`.
Hence, this commit removes `--keep-going` from `test`/`bench` and
provides guidance of `--no-fail-fast` instead.
If people really want to build as many tests as possible, they can also
do it in two steps:
cargo build --tests --keep-going
cargo test --test --no-fail-fast
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
