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
Support linker with -Zdoctest-xcompile.
This adds support for `-Clinker` with `-Zdoctest-xcompile`.
I'm not entirely sure how `-Zdoctest-xcompile` was supposed to work without setting the linker. I tested this with std on arm-unknown-linux-gnueabihf with qemu. It seems to work (although it was quite slow).
Closes#7529.
This commit refactors the internals of Cargo to no longer have a
singular `--target` flag (and singular `requested_target` kind throught)
but to instead have a list. The semantics of multiple `--target` flags
is to build the selected targets for each of the input `--target` flag
inputs.
For now this is gated behind `-Zmultitarget` as an unstable features,
since I'm not entirely sure this is the interface we want. In general
it'd be great if we had a way to simply specify `Unit` structures of
what to build on the CLI, but we're in general very far away from that,
so I figured that this is probably sufficient at least for testing for
now.
cc #8156
If an error occurs while compiling a metabuild target with
`--message-format=json`, it would panic because it was unable to serialize
`Target`. This change makes it so that it places a fake "metabuild.rs" string in
the `src_path` in this situation.
I'm very unhappy with this solution, but I'm unable to think of something
better. Changing `src_path` to an `Option` (or something) would break existing
tools. I tried implementing something that resets the `src_path` to the correct
path in the target dir after the workspace is configured, but it felt very
brittle – you have to fix up after all dependencies are downloaded, and there's
not a good way to ensure that happens correctly.
This adds a `with_json_contains_unordered` to help with tests.
- Fix: `cargo test --all-targets` was running lib tests three times.
- `--all-targets` help strings were wrong or misleading.
- Minor cleanup to add `Proposal` type to maybe make the code more readable.
- Use new enum `TargertSourcePath` for Target::src_path to make it explicit that metabuild has a special path.
- `cargo metadata` now skips the metabuild Target.
- JSON artifacts include the true path to the metabuild source file. This may not be the best solution, but it's unclear what it should be, and I would prefer to avoid breaking the output. Alternatively it could just not emit anything? I'm not completely familiar with the use case of these artifact messages.
- Place the file in `target/.metabuild/metabuild-pkgname-HASH.rs` instead of in the debug/release directory. Its contents do not depend on the profile.
- Fix bug in write_if_changed.
- More tests.
Fixes#5650. cc #5435
As part of my recent work on profiles, I introduced some situations where a
library can be compiled multiple times with different settings. Doctests were
greedily grabbing all dependencies for a package, regardless of which target
is was for. This can cause doctests to fail if it links multiple copies of
the same library.
One way to trigger this is `cargo test --release` if you have dependencies, a
build script, and `panic="abort"`. There are other (more obscure) ways to
trigger it with profile overrides.
While this might seem like too trivial of a stylistic nitpick to deserve
its own commit, this is needed to unblock rust-lang/rust#46980 (which makes
the unused-parens lint look at function arguments).
This commit is the initial steps to migrate Cargo's error handling from the
`error-chain` crate to the `failure` crate. This is intended to be a low-cost
(in terms of diff) transition where possible so it's note "purely idiomatic
`failure` crate" just yet.
The `error-chain` dependency is dropped in this commit and Cargo now canonically
uses the `Error` type from the `failure` crate. The main last remnant of
`error-chain` is a custom local extension trait to use `chain_err` instead of
`with_context`. I'll try to follow up with a commit that renames this later but
I wanted to make sure everything worked first! (and `chain_err` is used
practically everywhere).
Some minor tweaks happened in the tests as I touched up a few error messages
here and there but overall the UI of Cargo should be exactly the same before and
after this commit.
If a single unit-test fails, report a rerun-hint for it,
even with --no-fail-fast.
Fixes reporting a doctest-hint if doctest succeeds while
unittest fail with --no-fail-fast.
Fixes#4534
Eric Huss
bors
Arpad Borsos
Gus Wynn
Alex Crichton
Tom Dohrmann
Dario Gonzalez
Collins Abitekaniza
Dale Wijnand
Alexander Regueiro
Eh2406
Zach Lute
Wim Looman
Aleksey Kladov
Dirkjan Ochtman
Zack M. Davis
Anthony Ramine
Lukas Lueg