This is intended to help with adding more usage of anyhow in the
testsuite, which can help show context for errors.
This also includes some small improvements to the error messages to
provide more information.
Fix package_default_run test.
The `package_default_run` test was checking the output of `cargo metadata`, which included the "targets" field. Unfortunately the order of the targets in this test depend on the filesystem order, so the test may randomly fail.
The fix here is to just check for the one field that this test was interested in.
An alternate solution would be to sort the targets. Another alternate solution would be to use `"{...}"` for the targets to ignore them. I kinda liked simplifying it to check just one field.
This includes a series of commits that are just general changes to the test infrastructure:
* Change cargo-test-support to use anyhow.
* Remove unused `ErrMsg`.
* Fix a bug with `verify_checks_output`.
* Remove the weird Debug impl for Execs.
* Added a helper function for getting the JSON output from cargo. (I can imagine a lot of possible enhancements here.)
The output was checking the `targets`, whose order depends on the
filesystem order. Instead of checking all the output, just
check the one field this test is for.
Change how the fix_deny_warnings_but_not_others test works
This changes how the `fix_deny_warnings_but_not_others` test works to avoid breakage from a new compiler suggestion that affects rustfix. It should still test the same thing, but through a slightly different mechanism to avoid breaking when new compiler suggestion are added.
Relevant PR for rust-lang/rust: https://github.com/rust-lang/rust/pull/83004
Full explanation in this comment: https://github.com/rust-lang/rust/pull/83004#issuecomment-859155118
Please let me know if you have a better suggestion for this fix. I believe [we're trying to land this ASAP because the beta is being cut tomorrow](https://github.com/rust-lang/rust/pull/83004#issuecomment-858481702), so I will try to get back to any feedback as soon as possible.
cc `@pnkfelix`
Add mising documentation regarding `cargo doc`
It seems that the `--document-private-items` flag for `cargo doc` is automatically set when documenting a binary target. This change mentions that in the doc page.
The documentation did not mention this before, and it got me confused whilst I was trying to track down something going wrong.
Fix rustc/rustdoc config values to be config-relative.
The `rustc`, `rustdoc`, `rustc_wrapper`, and `rustc_workspace_wrapper` config values (in the `[build]` table) were being interpreted literally. This caused a problem if you used a relative path like `foo/rustc`. This would be interpreted as a relative path from whatever cwd cargo launches rustc from, which changes for different scenarios, making it essentially unusuable (since crates.io dependencies wouldn't be buildable).
Additionally, due to https://github.com/rust-lang/rust/issues/37868, it is a bad idea to use relative paths.
This changes it so that those paths are config-relative. Bare names (like "my-rustc-program") still use PATH as before.
This also includes a commit to centralize the rustc-wrapper program used by several tests so that it isn't built multiple times (and to allow several tests to work on windows).
Fixes#8202
Warn if an "all" target is specified, but we don't match anything
If a combination of --bins, --benches, --examples, --tests flags have
been specified, but we didn't match on anything after resolving the unit-list,
we emit a warning to make it clear that cargo didn't do anything and that the
code is unchecked.
This is my first PR and there are a couple things that I'm unsure about
* The integration test covers only one case (ideally it should cover every combination of the above mentioned flags the user can pass). I figured since the warning function is so simple, it'd best not to clog the testsuite with unnecessary `p.cargo().runs()` and whatnot. If I should make the test more comprehensive I can do that, it's also very easy to write unit tests so i can do that as well if needed.
* I figure we don't actually have to check the `--all-targets`, but i'm doing so for consistency. I also didn't check for the `--lib` flag at all because (I'm assuming) if the user passes `--lib` and there are no libraries, we error.
Edit: I notice (among other things) we sometimes silently skip certain units that have incompatible feature flags (see [here](ed0c8c6d66/src/cargo/ops/cargo_compile.rs (L1140))) so maybe we should be checking the `--lib` flag after all, in the event that a library was silently skipped and we no-opped 🤔
And thanks to `@ehuss` for taking the time to answer my questions and helping me through the contribution process, much appreciated
Closes#9536
If a combination of --bins, --benches, --examples, --tests flags have
been specified, but we didn't match on anything after resolving the unit-list,
we emit a warning to make it clear that cargo didn't do anything and that the
code is unchecked.
Closes#9536
Add `--prune` option for cargo-tree
Part of #8105
Prune the given package from the display of the dependency tree. Also providing a nice suggestion if the package is not within the resolved dependency graph.
Add additional test for CJK progress width
Not clear if CJK test hit boundary, since CJK characters have double width,
if we show an example with an extra single width means one of them hit
character boundary to be able to test ellipsis handling.
