Rollup of 6 pull requests
Successful merges:
- #139107 (std: make `cmath` functions safe)
- #139607 (Add regression test for #127424)
- #139691 (Document that `opt-dist` requires metrics to be enabled)
- #139707 (Fix comment in bootstrap)
- #139708 (Fix name of field in doc comment)
- #139709 (bootstrap: fix typo in doc string)
r? `@ghost`
`@rustbot` modify labels: rollup
Rollup of 8 pull requests
Successful merges:
- #139163 (indirect-const-stabilize the `exact_div` intrinsic)
- #139276 (Revert "Disable `f16` on Aarch64 without `neon`")
- #139315 (Switch `time` to `jiff` for time formatting in ICE dumps)
- #139382 (Update windows-bindgen to 0.61.0)
- #139688 (rustdoc-search: add unbox flag to Result aliases)
- #139701 (docs: clarify uint exponent for `is_power_of_two`)
- #139705 (Removed outdated ui test suite README, give reasons for disabled tests)
- #139713 (Fix typo in documentation)
r? `@ghost`
`@rustbot` modify labels: rollup
Add regression test for #127424
Fixes: https://github.com/rust-lang/rust/issues/127424
This ICE no longer reproduces, so it appears to have already been fixed.
This PR adds a regression test to ensure the issue doesn’t come back in the future.
Please let me know if there's anything I should improve or revise!
std: make `cmath` functions safe
The floating point intrinsics are more difficult, I'll probably wait until #119899 has merged before making them safe as well.
Removed outdated ui test suite README, give reasons for disabled tests
### Changes
- `tests/ui/README.md` is very outdated, test suite docs should consistently live in rustc-dev-guide.
- Add reasons for `//@ ignore-test` tests that don't have one.[^query]
This is a precursor change to make follow-up changes easier (possibly more specialized directives or converting some auxiliaries into the canonical `auxiliary/` form).
[^query]: searched via `rg --no-ignore -F -e "ignore-test" tests/`.
docs: clarify uint exponent for `is_power_of_two`
This makes the documentation more explicit for that method. I know this might seem "nit-picky", but `k` could be interpreted as "any Real or Complex number". A trivial example would be $`3 = 2^{log_2(3)}`$ which "proves that three is a power of two" (according to that vague definition).
BTW, when I read the implementation, I was surprised to see that `1` is considered a power of 2 despite being odd (it does make sense in some contexts, but still not intuitive). So I wrote "positive int" before correcting it to "unsigned int"
Update windows-bindgen to 0.61.0
This updates the automatically generate Windows API bindings. Not much changed this time:
- There's now `Default` implementations for many types, which is convenient. It does however conflict with one place where we implemented a non-zeroed default (to set the length field). But that's no big problem.
- The `--no-core` flag has been renamed to `--no-deps` to more accurately reflect its meaning (i.e. generate all necessary code without requiring additional dependencies).
- The `--link` flag allows us to set the location of the `link!` macro. Currently we use our workspace's `windows_targets` crate but we could move it into library/std using `--link`. However, this would need to be co-ordinated with the `backtrace` crate (which is a separate crate but included in std using `#[path]`). So I've left that for another time.
Switch `time` to `jiff` for time formatting in ICE dumps
Due to https://github.com/jhpratt/deranged/issues/21, Clippy, R-A and Miri currently fail to build if we bump to 0.4.1, pulled in via `time`. ~~Add some specific type annotations so we don't have to just pin it.~~
~~I can open 3 PRs to the tool repos if preferred, but I thought it might be easier to do this than to pin the transitive dep and go back and remove it once the changes are synced back.~~
run-make-support: Calculate artifact names for target platform, not host platform
This was implemented incorrectly during the porting process, where we relied on std consts. However, `run-make-support` is a host-only library, which meant that these artifact names were for the *host* and not the *target*.
Helps with #138066.
r? `@Kobzol`
try-job: armhf-gnu
try-job: test-various
try-job: x86_64-msvc-1
try-job: i686-msvc-1
try-job: x86_64-mingw-1
try-job: aarch64-apple
try-job: x86_64-apple-1
Update cargo
12 commits in 0e93c5bf6a1d5ee7bc2af63d1afb16cd28793601..864f74d4eadcaea3eeda37a2e7f4d34de233d51e
2025-04-05 00:00:24 +0000 to 2025-04-11 20:37:27 +0000
- chore: Bump build-rs version (rust-lang/cargo#15421)
- fix(build): Correct name of CARGO_CFG_FEATURE (rust-lang/cargo#15420)
- Revert "fix(package): detect dirtiness for symlinks to submodule" (rust-lang/cargo#15419)
- Improved error message when build-dir template var is invalid (rust-lang/cargo#15418)
- Added validation for unmatched brackets in build-dir template (rust-lang/cargo#15414)
- fix(package): detect dirtiness for symlinks to submodule (rust-lang/cargo#15416)
- chore(deps): bump crossbeam-channel from 0.5.14 to 0.5.15 (rust-lang/cargo#15415)
- docs(metadata): Added build_directory to cargo metadata documentation (rust-lang/cargo#15410)
- Added symlink resolution for `workspace-path-hash` (rust-lang/cargo#15400)
- feat: print target and package names formatted as file hyperlinks (rust-lang/cargo#15405)
- docs(ref): Use better example value in `CARGO_CFG_TARGET_ABI` (rust-lang/cargo#15404)
- chore: Bump cargo-util-schemas to 0.8.2 (rust-lang/cargo#15403)
r? ghost
Some tests fail on cross-compiled targets due to various linker problems
on cross-compiled target, and having test coverage for these against
cross-compiled targets is nice but not necessary.
This was implemented incorrectly during the porting process, where we
relied on std consts. However, `run-make-support` is a host-only
library, which meant that these artifact names were for the *host* and
not the *target*.
Polymorphize `array::IntoIter`'s iterator impl
Today we emit all the iterator methods for every different array width. That's wasteful since the actual array length never even comes into it -- the indices used are from the separate `alive: IndexRange` field, not even the `N` const param.
This PR switches things so that an `array::IntoIter<T, N>` stores a `PolymorphicIter<[MaybeUninit<T>; N]>`, which we *unsize* to `PolymorphicIter<[MaybeUninit<T>]>` and call methods on that non-`Sized` type for all the iterator methods.
That also necessarily makes the layout consistent between the different lengths of arrays, because of the unsizing. Compare that to today <https://rust.godbolt.org/z/Prb4xMPrb>, where different widths can't even be deduped because the offset to the indices is different for different array widths.
Rollup of 7 pull requests
Successful merges:
- #137835 (Use `BinOp::Cmp` for `iNN::signum`)
- #139584 (Avoid a reverse map that is only used in diagnostics paths)
- #139638 (Cleanup the `InstSimplify` MIR transformation)
- #139653 (Handle a negated literal in `eat_token_lit`.)
- #139662 (Tweak `DefPathData`)
- #139664 (Reuse address-space computation from global alloc)
- #139687 (Add spastorino to users_on_vacation)
r? `@ghost`
`@rustbot` modify labels: rollup
Avoid a reverse map that is only used in diagnostics paths
r? `@petrochenkov`
iterating a map until a value matches and returning the key is bad obviously, but it happens very rarely and only on diagnostics paths. It would also be a lot cheaper with https://github.com/rust-lang/rust/pull/138995. Which is actually why I'm trying this out, that PR adds a new entry in `create_def`, which makes `create_def` show up in cachegrind. So I'm trying out if removing adding an entry in `create_def` is a perf improvement
Use LTO to optimize Rust tools (cargo, miri, rustfmt, clippy, Rust Analyzer)
Trying if LTO/PGO can help RA's performance, and by how much. As `@Noratrieb` suggested, we could actually LTO optimize all the important tools.
CC `@Veykril` I realized that we don't even do LTO for Rust Analyzer, that could be a very low hanging fruit to improve its performance 😅
try-job: dist-x86_64-linux
Prepend temp files with per-invocation random string to avoid temp filename conflicts
https://github.com/rust-lang/rust/issues/139407 uncovered a very subtle unsoundness with incremental codegen, failing compilation sessions (due to assembler errors), and the "prefer hard linking over copying files" strategy we use in the compiler for file management.
Specifically, imagine we're building a single file 3 times, all with `-Csave-temps -Cincremental=...`. Let's call the object file we're building for the codegen unit for `main` "`XXX.o`" just for clarity since it's probably some gigantic hash name:
```
#[inline(never)]
#[cfg(any(rpass1, rpass3))]
fn a() -> i32 {
0
}
#[cfg(any(cfail2))]
fn a() -> i32 {
1
}
fn main() {
evil::evil();
assert_eq!(a(), 0);
}
mod evil {
#[cfg(any(rpass1, rpass3))]
pub fn evil() {
unsafe {
std::arch::asm!("/* */");
}
}
#[cfg(any(cfail2))]
pub fn evil() {
unsafe {
std::arch::asm!("missing");
}
}
}
```
Session 1 (`rpass1`):
* Type-check, borrow-check, etc.
* Serialize the dep graph to the incremental working directory `.../s-...-working/`.
* Codegen object file to a temp file `XXX.rcgu.o` which is spit out in the cwd.
* Hard-link[^1] `XXX.rcgu.o` to the incremental working directory `.../s-...-working/XXX.o`.
* Save-temps option means we don't delete `XXX.rgcu.o`.
* Link the binary and stuff.
* Finalize[^2] the working incremental session by renaming `.../s-...-working` to ` s-...-asjkdhsjakd` (some other finalized incr comp session dir name).
Session 2 (`cfail2`):
* Load artifacts from the previous *finalized* incremental session, namely the dep graph.
* Type-check, borrow-check, etc. since the file has changed, so most dep graph nodes are red.
* Serialize the dep graph to the incremental working directory `.../s-...-working/`.
* Codegen object file to a temp file `XXX.rcgu.o`. **HERE IS THE PROBLEM**: The hard-link is still set up to point to the inode from `XXX.o` from the first session, so this also modifies the `XXX.o` in the previous finalized session directory.
* Codegen emits an error b/c `missing` is not an instruction, so we abort before finalizing the incremental session. Specifically, this means that the *previous* session is the last finalized session.
Session 3 (`rpass3`):
* Load artifacts from the previous *finalized* incremental session, namely the dep graph. NOTE that this is from session 1.
* All the dep graph nodes are green since we are basically replaying session 1.
* codegen object file `XXX.o`, which is detected as *reused* from session 1 since dep nodes were green. That means we **reuse** `XXX.o` which had been dirtied from session 2.
* Link the binary and stuff.
This results in a binary which reuses some of the build artifacts from session 2, but thinks it's from session 1.
At this point, I hope it's clear to see that the incremental results from session 1 were dirtied from session 2, but we reuse them as if session 1 was the previous (finalized) incremental session we ran. This is at best really buggy, and at worst **unsound**.
This isn't limited to `-C save-temps`, since there are other combinations of flags that may keep around temporary files (hard linked) in the working directory (like `-C debuginfo=1 -C split-debuginfo=unpacked` on darwin, for example).
---
This PR implements a fix which is to prepend temp filenames with a random string that is generated per invocation of rustc. This string is not *deterministic*, but temporary files are transient anyways, so I don't believe this is a problem.
That means that temp files are now something like... `{crate-name}.{cgu}.{invocation_temp}.rcgu.o`, where `{invocation_temp}` is the new temporary string we generate per invocation of rustc.
Fixes https://github.com/rust-lang/rust/issues/139407
[^1]: 175dcc7773/compiler/rustc_fs_util/src/lib.rs (L60)
[^2]: 175dcc7773/compiler/rustc_incremental/src/persist/fs.rs (L1-L40)
Fix breakage when running compiletest with `--test-args=--edition=2015`
Compiletest has an `--edition` flag to change the default edition tests are run with. Unfortunately no test suite successfully executes when that flag is passed. If the edition is set to something greater than 2015 the breakage is expected, since the test suite currently supports only edition 2015 (Ferrous Systems will open an MCP about fixing that soonish). Surprisingly, the test suite is also broken if `--edition=2015` is passed to compiletest. This PR focuses on fixing the latter.
This PR fixes the two categories of failures happening when `--edition=2015` is passed:
* Some edition-specific tests set their edition through `//@ compile-flags` instead of `//@ edition`. Compiletest doesn't parse the compile flags, so it would see no `//@ edition` and add another `--edition` flag, leading to a rustc error.
* Compiletest would add the edition after `//@ compile-flags`, while some tests depend on flags passed to `//@ compile-flags` being the last flags in the rustc invocation.
Note that for the first category, I opted to manually go and replace all `//@ compile-flags` setting an edition with an explicit `//@ edition`. We could've changed compiletest to instead check whether an edition was set in `//@ compile-flags`, but I thought it was better to enforce a consistent way to set the edition in tests.
I also added the edition to the stamp, so that changing `--edition` results in tests being re-executed.
r? `@jieyouxu`
