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
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`
PR #137977 changed `DefPathData::TypeNs` to contain `Option<Symbol>` to
account for RPITIT assoc types being anonymous. This commit changes it
back to `Symbol` and gives anonymous assoc types their own variant. It
makes things a bit nicer overall.
Improve `AssocItem::descr`.
The commit adds "associated" to the description of associated types and associated consts, to match the description of associated functions. This increases error message precision and consistency with `AssocKind::fmt`.
The commit also notes an imperfection in `AssocKind::fmt`; fixing this imperfection is possible but beyond the scope of this PR.
r? `@estebank`
Allow parenthesis around inferred array lengths
In #135272 it was noticed that we weren't handling `Vec<(((((_)))))>` correctly under the new desugaring for `generic_arg_infer`, this had to be fixed in order to not regress stable code for types that should continue working. This has the side effect of *also* allowing the following to work:
```rust
#![feature(generic_arg_infer)]
struct Bar<const N: usize>;
fn main() {
let a: Bar<((_))> = Bar::<10>;
}
```
However I did not make the same change for array lengths resulting in the following not compiling:
```rust
#![feature(generic_arg_infer)]
fn main() {
let a: [u8; (((_)))] = [2; 2];
let a: [u8; 2] = [2; (((((_)))))];
}
```
This is rather inconsistent as parenthesis around `_` *are* supported for const args to non-arrays, and type args. This PR fixes this allowing the above example to compile. No stable impact.
r? compiler-errors
Deeply normalize obligations in `BestObligation` folder
Built on #139513.
This establishes a somewhat rough invariant that the `Obligation`'s predicate is always deeply normalized in the folder; when we construct a new obligation we normalize it.
Putting this up for discussion since it does affect some goals.
r? lcnr
