Beta 1.54 backports
This backports the following changes to 1.54 beta:
* #9595 — Relax doc collision error. This was an unintended regression where a warning was switched to an error in 1.54.
* #9563 — Change rustc-cdylib-link-arg error to a warning. Validation was added in #9523 (1.54) that generated an error. However, it was unknown at the time that use of link args via dependencies was being used. Rather than regress those projects (which has been on stable since 1.50), this switches the validation to a warning to indicate this was not intended.
* #9604 — Disambiguate is_symlink. Required to get CI to pass.
Disambiguate is_symlink.
`Path::is_symlink` was added in https://github.com/rust-lang/rust/pull/85747 which triggers the `unstable_name_collisions` lint, breaking Cargo's CI. This switches it to a free function to avoid the collision.
Relax doc collision error.
#9526 moved the `cargo doc` output name collision code to be shared with the other collision detection code. However, the way it detected collisions wasn't quite the same, and started generating errors for situations that were just warnings before. It was intended that the code should behave the same, so this PR relaxes the checks to be more like the original code. (It's still not 100% the same, but should be close enough.)
Closes#9564
Change `rustc-cdylib-link-arg` error to a warning.
In #9523, an error was added if `cargo:rustc-cdylib-link-arg` was issued in a build script without actually having a cdylib target. This uncovered that there was an unintentional change in #8441 to cause those link args to be applied to transitive dependencies.
This changes it so that the error is now a warning, with a note that this may become an error in the future. It also changes it so that the unstable `rustc-link-arg*` instructions only apply to the package that emitted them.
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.
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.
Replace deprecated `[replace]` references with `[patch]`
Cf. #7092.
Note: Untested, but given the changes I figure that if the testsuite passes it should be fairly safe.
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
Add a note about rustflags compatibility.
Over time, Cargo occasionally starts issuing new flags that may conflict with flags the user is passing directly to the compiler. Some recent examples are `-C embed-bitcode` (which broke anyone passing `-Clto` manually), and `-C prefer-dynamic` (which is kind of a mess). Future conflicts might be things like `--remap-path-prefix` or `--extern-html-root-url` (for rustdoc). This adds a note to mention these potential conflicts.
Although we try to maintain backwards compatibility as much as possible throughout all of Cargo, this particular area I think is dangerous enough that it is prudent to have some kind of warning somewhere. It is very rare that conflicts arise in practice, but they can happen.
I also added a note about passing in flags that Cargo itself issues, which can cause problems. Closes#9358.
Consolidate doc collision detection.
This removes the separate collision detection pass (in cargo_doc.rs) and uses the global collision detection instead. This removes the separate pass for running the resolver (which resulted in running the resolver four times every time `cargo doc` was run).
The `--open` option needs to know which path to open, so this is passed in a roundabout way via `Compilation`. Since this method uses the root units, I added a sort on the roots so that the crate that is opened is consistent between runs. This results in some slight behavioral changes.
This also makes the collision check slightly more stringent. The test `doc_multiple_targets_same_name` now generates an error instead of a warning because the old code did not check for collisions between libs and bins across packages (which should be very rare).
Add `--depth` option for `cargo-tree`
Part of #8105
Note that the `--depth` option only regards the "tree" depth but not dependency depth.
## To resolve
Bike-shedding naming problem: `-L,--level` or `--depth`?
`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.
