Update cargo
22 commits in 2622e844bc1e2e6123e54e94e4706f7b6195ce3d..ab1463d632528e39daf35f263e10c14cbe590ce8
2025-02-28 12:33:57 +0000 to 2025-03-08 01:45:05 +0000
- test: redact host target when comparing CARGO_ENV path (rust-lang/cargo#15279)
- feat: add completions for install --path (rust-lang/cargo#15266)
- fix(package): report lockfile / workspace manifest is dirty (rust-lang/cargo#15276)
- feat(tree): Add `--depth public` behind `-Zunstable-options` (rust-lang/cargo#15243)
- Don't use `$CARGO_BUILD_TARGET` in `cargo metadata` (rust-lang/cargo#15271)
- feat: show extra build description from bootstrap (rust-lang/cargo#15269)
- Upgrade to `rustc-stable-hash v0.1.2` (rust-lang/cargo#15268)
- fix: Respect --frozen everywhere --offline or --locked is accepted (rust-lang/cargo#15263)
- feat(tree): Color the output (rust-lang/cargo#15242)
- fix(vendor): dont remove non-cached source (rust-lang/cargo#15260)
- docs: lockfile is always included since 1.84 (rust-lang/cargo#15257)
- Remove `Cargo.toml` from `package.include` in example (rust-lang/cargo#15253)
- Small cleanup: remove unneeded result (rust-lang/cargo#15256)
- Fix typo in build-scripts.md (rust-lang/cargo#15254)
- chore(deps): update rust crate pulldown-cmark to 0.13.0 (rust-lang/cargo#15250)
- chore(deps): update compatible (rust-lang/cargo#15249)
- feat(cli): forward bash completions of third party subcommands (rust-lang/cargo#15247)
- feat: add completions for `--lockfile-path` (rust-lang/cargo#15238)
- fix: reset $CARGO if the running program is real `cargo[.exe]` (rust-lang/cargo#15208)
- Get all members as `available targets` even though default-members was specified. (rust-lang/cargo#15199)
- refactor: control byte display precision with std::fmt options (rust-lang/cargo#15246)
- fix(package): Ensure we can package directories ending with '.rs' (rust-lang/cargo#15240)
Change TaskDeps to start preallocated with 128 capacity
This is a tiny change that makes `TaskDeps::read_set` start preallocated with capacity for 128 elements.
From local profiling, it looks like `TaskDeps::read_set` is one of the most-often resized hash-sets in `rustc`.
add `tool::CargoClippy` and `tool::Cargofmt` binary to target sysroot
When running `x build clippy`, we expect `stage1-tool-bin/cargo-clippy` and `stage2/bin/cargo-clippy` to be the same, but they aren't. This happens because `tool::CargoClippy` doesn't place its binary in the `stage2` directory. As a result, `stage1-tool-bin/cargo-clippy` comes from `tool::CargoClippy`, while `stage2/bin/cargo-clippy` comes from `tool::Cargo`. Same applies for `tool::Cargofmt`.
This PR fixes the issue by adding `tool::CargoClippy` and ``tool::Cargofmt`` binaries to the expected sysroot and makes sure both directories share the same binary.
To test this, run `x build --stage 2 compiler clippy rustfmt`, link the stage2 sysroot with rustup, and then call `cargo +stage2 fmt` and `cargo +stage2 clippy` on any rust project (it wouldn't work without this PR).
Don't re-`assume` in `transmute`s that don't change niches
I noticed in nightly 2025-02-21 that `transmute` is emitting way more `assume`s than necessary for newtypes.
For example, the three transmutes in <https://rust.godbolt.org/z/fW1KaTc4o> emits
```rust
define noundef range(i32 1, 0) i32 `@repeatedly_transparent_transmute(i32` noundef range(i32 1, 0) %_1) unnamed_addr {
start:
%0 = sub i32 %_1, 1
%1 = icmp ule i32 %0, -2
call void `@llvm.assume(i1` %1)
%2 = sub i32 %_1, 1
%3 = icmp ule i32 %2, -2
call void `@llvm.assume(i1` %3)
%4 = sub i32 %_1, 1
%5 = icmp ule i32 %4, -2
call void `@llvm.assume(i1` %5)
%6 = sub i32 %_1, 1
%7 = icmp ule i32 %6, -2
call void `@llvm.assume(i1` %7)
%8 = sub i32 %_1, 1
%9 = icmp ule i32 %8, -2
call void `@llvm.assume(i1` %9)
%10 = sub i32 %_1, 1
%11 = icmp ule i32 %10, -2
call void `@llvm.assume(i1` %11)
ret i32 %_1
}
```
But those are all just newtypes that don't change size or niches, so none of it's needed.
After this PR it's down to just
```rust
define noundef range(i32 1, 0) i32 `@repeatedly_transparent_transmute(i32` noundef range(i32 1, 0) %_1) unnamed_addr {
start:
ret i32 %_1
}
```
because none of those `assume`s in the original actually did anything.
(Transmuting to something with a difference niche, though, still has the assumes -- the other tests continue to pass checking that.)
Don't include global asm in `mir_keys`, fix error body synthesis
r? oli-obk
Fixes#137470Fixes#137471Fixes#137472Fixes#137473
try-job: test-various
try-job: x86_64-apple-2
Rollup of 12 pull requests
Successful merges:
- #137337 (Add verbatim linker to AIXLinker)
- #137363 (compiler: factor Windows x86-32 ABI impl into its own file)
- #137537 (Prevent `rmake.rs` from using unstable features, and fix 3 run-make tests that currently do)
- #137606 (add a "future" edition)
- #137957 (Remove i586-pc-windows-msvc)
- #138000 (atomic: clarify that failing conditional RMW operations are not 'writes')
- #138013 (Add post-merge analysis CI workflow)
- #138033 (rustdoc: Add attribute-related tests for rustdoc JSON.)
- #138137 (setTargetTriple now accepts Triple rather than string)
- #138173 (Delay bug for negative auto trait rather than ICEing)
- #138184 (Allow anyone to relabel `CI-spurious-*`)
- #138187 (remove clones)
r? `@ghost`
`@rustbot` modify labels: rollup
rustdoc: Add attribute-related tests for rustdoc JSON.
Add rustdoc JSON tests covering the use of the following attributes:
- `#[non_exhaustive]` applied to enums, variants, and structs
- `#[must_use]`, both with and without a message
- `#[no_mangle]`, in both edition 2021 and 2024 (`#[unsafe(no_mangle)]`) flavors
- `#[export_name]`, also in both edition 2021 and 2024 flavors
Related to #137645; this is a subset of the attributes that `cargo-semver-checks` relies on and tests in its own test suite or in the test suites of its components such as `trustfall-rustdoc-adapter`.
Helps with #81359
r? `@aDotInTheVoid`
Add post-merge analysis CI workflow
This PR adds a post-merge analysis workflow, which was discussed [here](https://rust-lang.zulipchat.com/#narrow/channel/242791-t-infra/topic/Reporting.20test.20suite.20statistics.20after.20merge).
The workflow currently analyzes test suite results from bootstrap metrics. It downloads metrics for all known jobs in the parent and current (HEAD) commit, compares them and prints a truncated diff. It then posts this diff to the merged PR as a comment. Later I also want to add other statistics to the analysis, e.g. changes in CI/bootstrap step durations.
It can be tested locally e.g. using this:
```
cargo run --release --manifest-path src/ci/citool/Cargo.toml post-merge-report 3cb02729ab3c6583a3b1d1845c5e22b674f04b8d fd17deacce374a4185c882795be162e17b557050
```
This uses a slightly older commit as a parent, to have more results in the diff (normally the diff won't be so large).
CC `@jieyouxu`
r? `@marcoieni`
atomic: clarify that failing conditional RMW operations are not 'writes'
Fixes https://github.com/rust-lang/rust/issues/136669
r? ``@Amanieu``
Cc ``@rust-lang/opsem`` ``@chorman0773`` ``@gnzlbg`` ``@briansmith``
Remove i586-pc-windows-msvc
See [MCP 840](https://github.com/rust-lang/compiler-team/issues/840).
I left a specialized error message that should help users that hit this in the wild (for example, because they use it in their CI).
```
error: Error loading target specification: the `i586-pc-windows-msvc` target has been removed. Use the `i686-pc-windows-msvc` target instead.
Windows 10 (the minimum required OS version) requires a CPU baseline of at least i686 so you can safely switch. Run `rustc --print target-list` for a list of built-in targets
```
``@workingjubilee`` ``@calebzulawski`` fyi portable-simd uses this target in CI, if you wanna remove it already before this happens
add a "future" edition
This idea has been discussed previously [on Zulip](https://rust-lang.zulipchat.com/#narrow/channel/213817-t-lang/topic/Continuous.20edition-like.20changes.3F/near/432559262) (though what I've implemented isn't exactly the "next"/"future" editions proposed in that message, just the "future" edition). I've found myself prototyping changes that involve edition migrations and wanting to target an upcoming edition for those migrations, but none exists. This should be permanently unstable and not removed.
Prevent `rmake.rs` from using unstable features, and fix 3 run-make tests that currently do
Addresses (mostly) #137532.
Follow-up to #137373.
### Summary
- Fix 3 run-make tests that currently use unstable features:
1. `tests/run-make/issue-107495-archive-permissions/rmake.rs` uses `#![feature(rustc_private)]` for `libc` on `unix`, but `run_make_support` already exports `libc`, so just use that.
2. `tests/run-make/cross-lang-lto/rmake.rs` uses `#![feature(path_file_prefix)]` for convenience, replaced with similar filename prefix logic.
3. `tests/run-make/broken-pipe-no-ice/rmake.rs` uses `#![feature(anonymous_pipe)]` for anonymous pipes. This is more complicated[^race-condition], and I decided to temporarily introduce a dependency on [`os_pipe`] before std's `anonymous_pipe` library feature is stabilized[^pipe-stab]. I left a FIXME tracked by #137532 to make the switch once `anonymous_pipe` stabilizes and reaches beta.
- Use `RUSTC_BOOTSTRAP=-1` when building `rmake.rs` to have the stage 0 rustc reject any unstable features used in `rmake.rs`.
- The requirement that `rmake.rs` may not use any unstable features is now documented in rustc-dev-guide.
- This PR does not impose `RUSTC_BOOTSTRAP=-1` when building `run-make-support`, but I suppose we could.
r? `@Kobzol`
try-job: x86_64-msvc-1
try-job: x86_64-mingw-1
[`os_pipe`]: https://github.com/oconnor663/os_pipe.rs
[^race-condition]: We can't just try to spawn `rustc` and immediate close the stderr handle because of race condition, as there's no guarantee `rustc` will not try to print to stderr before the handle gets closed.
[^pipe-stab]: In-progress stabilization PR over at https://github.com/rust-lang/rust/pull/135822.
compiler: factor Windows x86-32 ABI impl into its own file
While it shares more than zero code with the SysV x86-32 ABI impl, there is no particular reason to organize wildly different ABIs using if-else in the same function.
Add verbatim linker to AIXLinker
This adds support for the "verbatim" native link modifier on AIX, will successfully pass the `native-link-modifier-verbatim-linker test case`
handle forced compiler and revert #137476
Fixes https://github.com/rust-lang/rust/issues/138004
I would appreciate it if we could measure CI pipelines with the current changes to see if this reduces recent CI overhead. cc `@rust-lang/infra`
try-job: dist-powerpc64le-linux
Inline `FnOnce`/`FnMut`/`Fn` shims once again
This PR fixes the argument checking for `extern "rust-call"` ABI functions with a spread arg, which do no expect their arguments to be exploded from a tuple like closures do.
Secondly, it removes the hack that prevented them from being inlined. This results in more work done by the compiler, but it does end up allowing us to inline functions we didn't before.
Fixes#137901
Rollup of 20 pull requests
Successful merges:
- #134063 (dec2flt: Clean up float parsing modules)
- #136581 (Retire the legacy `Makefile`-based `run-make` test infra)
- #136662 (Count char width at most once in `Formatter::pad`)
- #136764 (Make `ptr_cast_add_auto_to_object` lint into hard error)
- #136798 (Added documentation for flushing per #74348)
- #136865 (Perform deeper compiletest path normalization for `$TEST_BUILD_DIR` to account for compare-mode/debugger cases, and normalize long type file filename hashes)
- #136975 (Look for `python3` first on MacOS, not `py`)
- #136977 (Upload Datadog metrics with citool)
- #137240 (Slightly reformat `std::fs::remove_dir_all` error docs)
- #137298 (Check signature WF when lowering MIR body)
- #137463 ([illumos] attempt to use posix_spawn to spawn processes)
- #137477 (uefi: Add Service Binding Protocol abstraction)
- #137569 (Stabilize `string_extend_from_within`)
- #137633 (Only use implied bounds hack if bevy, and use deeply normalize in implied bounds hack)
- #137679 (Various coretests improvements)
- #137723 (Make `rust.description` more general-purpose and pass `CFG_VER_DESCRIPTION`)
- #137728 (Remove unsizing coercions for tuples)
- #137731 (Resume one waiter at once in deadlock handler)
- #137875 (mir_build: Integrate "simplification" steps into match-pair-tree creation)
- #138028 (compiler: add `ExternAbi::is_rustic_abi`)
r? `@ghost`
`@rustbot` modify labels: rollup
compiler: add `ExternAbi::is_rustic_abi`
Various parts of the compiler were hand-rolling this extremely simple check that is nonetheless easy to get wrong as the compiler evolves over time. Discourage them from being so "original" again by replacing it with a single implementation on the type that represents these ABIs. This simplifies a surprising amount of code as a result.
Also fixes#132981, an ICE that emerged due to other checks being made stricter.
mir_build: Integrate "simplification" steps into match-pair-tree creation
The “simplification” step helps to prepare THIR patterns for lowering into MIR, and originally dates back to the earliest days of MIR in the compiler.
Over time, various intermediate data structures have been introduced (e.g. `MatchPair`, later renamed to `MatchPairTree`) that reduce the need for a separate simplification step, because some of the necessary simplifications can be built into the construction of those intermediate structures instead. This PR continues that process to its logical conclusion and removes the simplification step entirely, by integrating its remaining responsibilities into match-pair-tree creation: flattening “irrefutable” nodes, collecting bindings/ascriptions in flat lists, and sorting or-patterns after other subpatterns.
This has a few immediate benefits:
- We can remove `TestCase::Irrefutable`, which was not allowed to exist after simplification, and was much larger than other test-case variants.
- We can make `MatchPairTree::place` non-optional, because only irrefutable nodes could fail to have a place.
In the future, this should also help with some ideas I have for simplifying how `AscribeUserType` and `ExpandedConstant` nodes are handled, by representing them as side-data keyed by THIR pattern ID, so that they are no longer their own kinds of THIR pattern node.
Resume one waiter at once in deadlock handler
When multiple query loop errors occur in the code, only one waiter should be resumed at a time to avoid waking up multiple waiters at the same time and causing deadlock due to thread grabbing.
This fixes the UI failures in #132051
cc `@Zoxc` `@cjgillot` `@nnethercote` `@bjorn3` `@Kobzol`
Zulip discussion [here](https://rust-lang.zulipchat.com/#narrow/channel/187679-t-compiler.2Fwg-parallel-rustc/topic/Deadlocks.20and.20Rayon)
Edit: We can't reproduce these bugs with the existing test suits, so we keep them until we merge #132051
UPDATES #129912
UPDATES #120757
UPDATES #129911
Various coretests improvements
The first commit is not yet strictly necessary as directly testing libcore works though useless work, but will be necessary once https://github.com/rust-lang/rust/pull/136642 migrates the liballoc tests into a separate package. The second commit fixes https://github.com/rust-lang/rust/issues/137478 and ensures that coretests actually gets tested on all CI job. The third commit fixes an error that didn't get caught because coretests doesn't run on the wasm32 CI job.
Only use implied bounds hack if bevy, and use deeply normalize in implied bounds hack
Consolidates the implied bounds computation mode into a single function, which deeply normalizes, and if it's in **compat** mode (for bevy), it extracts outlives bounds from the infcx.
Previously, we were using the implied bounds compat mode in two cases:
1. During WF, if it detects `ParamSet`
2. EVERYWHERE ELSE (lol) -- e.g. borrowck, predicate entailment, etc.
While I think this is fine, and the net effect was just that we emitted fewer diagnostics, it makes me uncomfortable that all crates were using the supposed "compat" code.
Fixes#137767
bors
Tshepang Mbambo
许杰友 Jieyou Xu (Joe)
Deadbeef
Jacob Pratt
Ben Kimock
Ralf Jung
The Miri Cronjob Bot
moxian