1.44.1 stable backports
Tried to duplicate https://github.com/rust-lang/cargo/pull/8335, though had to manually adjust 3b9e8dc4c1dc6a6ec714acb6a97b4f7cffda1176 (cherry-pick of #8329) as it had a merge conflict.
Stable backports for:
* #8329 — Don't hash executable filenames on apple platforms. (fix macos backtraces)
[beta] Fix `clean -p` with a build dependency.
This is a temporary and simple fix for #8149 where `cargo clean -p foo` would fail if `foo` has a build dependency. The full fix is in #8210, but I think that PR is way too risky to backport.
Allow `cargo package --list` even for things that don't package.
`cargo package --list` was changed in #7905 to generate `Cargo.lock` earlier. If there is a problem, then it would fail where previously it would succeed. This changes it so that file generation is deferred until after `--list`.
This also changes it so that the "dependencies must have a version" check is deferred until after `--list` as well.
Closes#8151
[beta] Do not probe for `-Cembed-bitcode`
This flag didn't make it to the beta branch of rustc, so remove the
probe here in Cargo. This is intended to be a very small patch to remove
the probe, since the real support is updated on master and will replace
this eventually anyway.
This flag didn't make it to the beta branch of rustc, so remove the
probe here in Cargo. This is intended to be a very small patch to remove
the probe, since the real support is updated on master and will replace
this eventually anyway.
Don't use debug display for error object.
When `cargo new` displays a workspace validation warning, it was using the debug display which we probably shouldn't rely on.
This also consolidates a similar usage when `cargo doc --open` fails.
Closes#8118
Add backwards-compatibility for old cargo-tree flags.
Add backwards compatibility for the flags that were removed.
`--invert` is still not backwards compatible because it was fundamentally changed to take an argument.
Requested via https://github.com/rust-lang/cargo/pull/8062#issuecomment-613829752.
Try to avoid panics on buggy (?) clocks
Try to avoid panics with `Instant` by only performing infallible
operations. This tweaks a comparison located in #8042 to use `Instant`
comparisons rather than `Duration` comparisons which should hopefully
eliminate a source of panics in the face of buggy (maybe?) clocks.
I'm not sure whether this actually fixes the original issue, but seeing
that we have a pretty low chance of the issue recurring, it's probably
fine to go ahead and say...
Closes#8042
Try to avoid panics with `Instant` by only performing infallible
operations. This tweaks a comparison located in #8042 to use `Instant`
comparisons rather than `Duration` comparisons which should hopefully
eliminate a source of panics in the face of buggy (maybe?) clocks.
I'm not sure whether this actually fixes the original issue, but seeing
that we have a pretty low chance of the issue recurring, it's probably
fine to go ahead and say...
Closes#8042
Update dependencies to support illumos target
Several dependencies of cargo require updates in order to build with illumos as the `target_os` platform (rust-lang/rust#55553). Most are patch revisions to include `#[cfg()]` updates. In the case of `fs2`, the maintainer does not appear to be minding activity on the project, so it was forked into `fs3`, maintaining the same interfaces and logic (but featuring the widened platform support).
Fix freshness when linking is interrupted.
Fixes a scenario where hitting Ctrl-C while linking would leave a corrupted executable, but Cargo would think it is "fresh" and fail to rebuild it.
This also includes a separate commit which adds more documentation on fingerprinting.
Fixes#7767
Add `cargo tree` command.
This migrates [cargo-tree](https://github.com/sfackler/cargo-tree/) into Cargo as a built-in command. This is based on a recent master (4108d216ec), and should be mostly similar in functionality. There are a variety changes:
* `--all-targets` renamed to `--no-filter-targets` to avoid confusion with the `--all-targets` flag used in other Cargo commands with a different meaning.
* `--all`/`-a` renamed to `--no-dedupe` to avoid confusion with the `-all` flag which means "all workspace crates" in other Cargo commands.
* `--duplicate` renamed to `--duplicates` (with alias), just a personal preference.
* Added support for multiple roots (workspace support).
* Added the `--graph-features` flag for including features in the graph (to "explain" why a feature is enabled).
* Added `{f}` to format string to show features.
* Handles new feature resolver.
* Handles cyclical dev dependencies.
* Added a test suite.
* Dropped the dependency on petgraph, in favor of a simpler custom graph.
Closes#7286.
Add "build-finished" JSON message.
This adds a JSON message when a build is finished. This is useful for tools to know when to stop parsing JSON, which is particularly useful for commands like `cargo test` or `cargo run` where additional output may follow.
Closes#7978
Extend -Zpackage-features with more capabilities.
This is a proposal to extend `-Zpackage-features` with new abilities to change how features are selected on the command-line. See `unstable.md` for documentation on what it does.
I've contemplated a variety of ways we could transition this to stable. I tried a few experiments trying to make a "transition with warnings" mode, but I'm just too concerned about breaking backwards compatibility. The current way is just fundamentally different from the new way, and I think it would be a bumpy ride to try to push it.
The stabilization story is that the parts of this that add new functionality (feature flags in virtual worskpaces, and `member/feat` syntax) can be stabilized at any time. The change for `cargo build -p member --features feat` in a different member's directory can maybe be part of `-Zfeatures` stabilization, which will need to be opt-in. I've been trying to come up with some transition plan, and I can't think of a way without making it opt-in, and making it part of `-Zfeatures` is an opportunity to simplify things. One concern is that this might be confusing (`--features` flag could behave differently in different workspaces, and documenting the differences), but that seems hard to avoid.
Closes#6195Closes#4753Closes#5015Closes#4106Closes#5362
Disallow invalid dependency names through crate renaming
resolves#6656
As suggested in the issue, I simply checked the dep names by calling `validate_package_name` on the dependencies during the TOML deserialization process.
It might be a bit too strict (and sudden) to error out in this case, so it might be best to convert this into a warning instead. However, this _is_ pretty invalid behavior so I'm not too sure really.
Use the same filename hash for pre-release channels.
This changes it so that filenames do not hash the entire verbose version from rustc if they are a pre-release version. The intent is to avoid leaving stale artifacts in the target directory whenever someone updates a nightly or beta release. This should help reduce disk space usage for someone who updates these toolchains frequently.
I tested with the rustc repo, and it seems to be OK. It keeps everything in separate target directories, so I think it should be generally safe. This should only affect someone switching between different nightlies and wanting to avoid recompiling when switching back. I suspect that is a rare use case, though if there are complaints this can be easily reverted (or made a config option). cargo-bisect-rustc should also be safe since it uses a different target directory for each toolchain.
One concern here for me was incremental support. It looks like ([src](6387b09153/src/librustc_incremental/persist/file_format.rs (L88-L100))) the incremental cache includes the detailed rustc version, so I think that is safe. It also looks like it is [smart enough](6387b09153/src/librustc_incremental/persist/load.rs (L40-L49)) to delete stale files.
We will need to be more careful in the future when changing the target directory structure or the format of files. We previously relied on the fact that each new nightly will use different filenames. If we change the structure in a backwards-incompatible way, we will need to be careful to update the version (`1.hash` in `compute_metadata`).
Compatibility for rust-lang/rust#69926
This adds compatibility for the rust-lang/rust#69926 PR, which makes it so a warning count is displayed when the build is done.
Add note about converting triple case in environment variables
This wasn't obvious to me, since `CARGO_TARGET_x86_64-unknown-linux-gnu_LINKER` is a perfectly valid environment variable name. It's especially important to document environment variable names well because if you get it wrong it is just silently ignored.
This wasn't obvious to me, since `CARGO_TARGET_x86_64-unknown-linux-gnu_LINKER` is a perfectly valid environment variable name. It's especially important to document environment variable names well because if you get it wrong it is just silently ignored.
