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.
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
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.
Configure hosts separately from targets when --target is specified.
This prevents target configs from accidentally being picked up when cross compiling from hosts that have the same architecture as their targets.
closes#3349
Add some validation to rustc-link-arg
This adds some validation, so that if a `cargo:rustc-link-arg-*` build script instruction specifies a target that doesn't exist, it will generate an error. This also changes a parse warning to an error if the `=` is missing from BIN=ARG.
I intentionally did not bother to add the validation to config overrides, as it is a bit trickier to do, and that feature is very rarely used (AFAIK), and I'm uncertain if rustc-link-arg is really useful in that context.
cc #9426
`cargo tree -e no-proc-macro` to hide procedural macro dependencies
Probably resolves#9165
`cargo tree -e no-proc-macro` now hides procedural macro dependencies.
Note that when passed with `--invert <spec>`, the spec's reverse proc-macro dependencies are also hidden. Is this desired result?
Also, since I want `-p <spec>` and `-i <spec>` works with any valid package-id in the project, the filter logic is written in print stage instead of graph build stage
Update to semver 1.0.0
I am working on a 1.0.0 of the `semver` crate some time this week. It would be good to confirm Cargo will be able to use it, beforehand!
It's a from-scratch rewrite, but https://github.com/dtolnay/semver/issues/237 has code to compare against 0.10.0 (currently used by Cargo) how every possible version requirement currently published to crates.io matches against every possible crate version. The differences are all broken syntax like `^0-.11.0` previously parsing with ".11.0" as a pre-release string (which is invalid, because pre-release are not allowed to contain empty dot-separated identifiers) and `~2.0-2.2` previously parsing with "2.2" as a pre-release string, when the user almost certainly meant `>=2.0, <=2.2`. I'm not sure how much of those you want to add code into Cargo to preserve behavior, but I would be happy to do it.
Add `cargo:rustc-link-arg-bin` flag.
This PR implements a `cargo:rustc-link-arg-bin` command to specify per-binary link args from build scripts. This follows the suggestion from the tracking issue #9426.
Syntax is `cargo:rustc-link-arg-bin=BIN_NAME=ARG`
This was previously possible to do using the `#[link_args=".."]` attribute, but it was removed in rust-lang/rust#83820 in favor of the Cargo extra-link-args feature, which can currently not specify different link args for different bins in the same crate. This PR adds back the ability to do that.
Add a cargo-doc.browser config option
The idea of this option is to allow cargo to use a separate browser from
the rest of the system. My motivation in doing this is that I want to
write a script that adds a symbolic link in some web root on my system
such that I can access my docs via the http protocol to avoid the
limitations of the file protocol that are accessibility problems for me.
For instance, zoom is not retained across multiple pages and Stylus
filters don't work well.
The idea of this option is to allow cargo to use a separate browser from
the rest of the system. My motivation in doing this is that I want to
write a script that adds a symbolic link in some web root on my system
such that I can access my docs via the http protocol to avoid the
limitations of the file protocol that are accessibility problems for me.
For instance, zoom is not retained across multiple pages and Stylus
filters don't work well.
Improve two error messages
The first error message saying "an integer" is confusing because if you give it `4` it's an integer but it will still complain that it must be an integer. So it's more specific now and tells you that it actually needs to be `1`, `2` or `3`.
In the second error there was a space missing. It says `is not a valid setting,must be`.
