Enforce in bootstrap that test must have stage at least 1 (except for compiletest)
This PR cleans up a bunch of test steps and adds metadata to them. I didn't yet touch the most complicated step (`CompileTest`), I'm leaving that for another PR.
Testing anything on stage 0 is only possible for compiletest and with `build.allow-compiletest-stage0`. Testing anything else on stage 0 will either produce a nice error or crash with a stage being subtracted below zero.
r? `@jieyouxu`
try-job: dist-x86_64-linux
try-job: aarch64-gnu
try-job: arm-android
try-job: `x86_64-gnu-llvm-20*`
try-job: `x86_64-msvc-*`
try-job: aarch64-apple
try-job: test-various
Rollup of 4 pull requests
Successful merges:
- rust-lang/rust#144443 (Make target pointer width in target json an integer)
- rust-lang/rust#145174 (Ensure consistent drop for panicking drop in hint::select_unpredictable)
- rust-lang/rust#145592 (Fix format string grammar in docs and improve alignment error message for rust-lang/rust#144023)
- rust-lang/rust#145931 (Clarify that align_offset overaligns)
r? `@ghost`
`@rustbot` modify labels: rollup
Clarify that align_offset overaligns
The current documentation is not clear whether adding `a` to a pointer overaligns (align up) or underaligns (align down).
It should say this explicitly.
cc `@nagisa`
Fix format string grammar in docs and improve alignment error message for #144023
This PR improves error messages and documentation for format strings involving alignment and formatting traits.
Highlights:
- Clearer error messages for invalid alignment specifiers (e.g., `{0:#X>18}`), showing the expected `<`, `^`, or `>` and a working example:
println!("{0:>#18X}", value);
- Updated UI test `format-alignment-hash.rs` to reflect the improved error output.
- Documentation clarification: ensures examples correctly show how width, alignment, and traits like `x`, `X`, `#` combine.
Motivation:
Previously, using `#` with alignment and width produced confusing errors. This PR guides users on the correct syntax and provides actionable examples.
Testing:
- Built the compiler (`./x build`)
- Blessed and ran UI tests (`./x. test src/test/ui/fmt/format-alignment-hash.rs --bless`)
- Verified full test suite passes (`./x test`)
Issue: rust-lang/rust#144023
Ensure consistent drop for panicking drop in hint::select_unpredictable
There are a few alternatives to the implementation. The principal problem is that the selected value must be owned (in the sense of having a drop flag of sorts) when the unselected value is dropped, such that panic unwind goes through the drop of both. This ownership must then be passed on in return when the drop went smoothly.
The basic way of achieving this is by extracting the selected value first, at the cost of relying on the optimizer a little more for detecting the copy as constructing the return value despite having a place in the body. Unfortunately, that causes LLVM to discard the !unpredictable annotation (for some reason that is beyond my comprehension of LLVM).
<details>
<summary>Extract from the build log showing an unannotated select being used</summary>
```
2025-08-09T16:51:06.8790764Z 39: define noundef i64 `@test_int2(i1` noundef zeroext %p, i64 noundef %a, i64 noundef %b) unnamed_addr #0 personality ptr `@rust_eh_personality` {
2025-08-09T16:51:06.8791368Z check:47'0 X~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ error: no match found
2025-08-09T16:51:06.8791700Z 40: start:
2025-08-09T16:51:06.8791858Z check:47'0 ~~~~~~~
2025-08-09T16:51:06.8792043Z 41: %ret.i = select i1 %p, i64 %a, i64 %b
2025-08-09T16:51:06.8792293Z check:47'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2025-08-09T16:51:06.8792686Z check:47'1 ? possible intended match
2025-08-09T16:51:06.8792946Z 42: ret i64 %ret.i
2025-08-09T16:51:06.8793127Z check:47'0 ~~~~~~~~~~~~~~~~
```
</details>
So instead, this PR includes a guard to drop the selected `MaybeUnit<T>` which is active only for the section where the unselected value is dropped. That leaves the code for selecting the result intact leading to the expected ir. That complicates the 'unselection' process a little bit since we require _both_ values as a result of that intrinsic call. Since the arguments alias, this portion as well as the drop guard uses raw pointers.
Closes: rust-lang/rust#145148
Prior: rust-lang/rust#139977
Use absolute path to llvm-bolt, merge-fdata rather than PATH
This unconditionally uses the provided LLVM toolchain's BOLT. I'm not sure that makes sense, but since we don't build BOLT as part of Rust's build of LLVM today, it's probably the right option for now.
This avoids breaking the build on not being able to find the llvm-bolt executable.
Detect missing `if let` or `let-else`
During `let` binding parse error and encountering a block, detect if there is a likely missing `if` or `else`:
```
error: expected one of `.`, `;`, `?`, `else`, or an operator, found `{`
--> $DIR/missing-if-let-or-let-else.rs:14:25
|
LL | let Some(x) = foo() {
| ^ expected one of `.`, `;`, `?`, `else`, or an operator
|
help: you might have meant to use `if let`
|
LL | if let Some(x) = foo() {
| ++
help: alternatively, you might have meant to use `let else`
|
LL | let Some(x) = foo() else {
| ++++
```
Fixrust-lang/rust#107806.
Update `browser-ui-test` version to `0.21.3`
I cannot test it locally because of this bug:
```
error: couldn't generate documentation: failed to read column from disk: data consumer error: missing field `unknown number` at line 1 column 8
|
= note: failed to create or modify "build/x86_64-unknown-linux-gnu/test/rustdoc-gui/doc/search.index/entry/": failed to read column from disk: data consumer error: missing field `unknown number` at line 1 column 8
```
So I'll iterate through CI checks I guess.
r? ghost
Fix `sys::process::windows::tests::test_thread_handle` spurious failure
Instead of sleeping, wait for the process to finish so that we can be sure it's done. We use a timeout because otherwise this test can be stuck indefinitely if it fails (unfortunately std doesn't currently have a way to wait with a timeout so a manual OS API call is necessary).
I also changed the test to run `whoami` and pipe the output to null so that it doesn't clutter up the test output.
Fixesrust-lang/rust#146024
This unconditionally uses the provided LLVM toolchain's BOLT. I'm not
sure that makes sense, but since we don't build BOLT as part of Rust's
build of LLVM today, it's probably the right option for now.
This avoids breaking the build on not being able to find the llvm-bolt
executable.
With a patch applied to count the number of unifications,
and running the query `Option<T>, (T -> U) -> Option<U>`
before: performed unifyFunctionType on 17484 functions
after: performed unifyFunctionType on 3055 functions
Remove incorrect fixme on deprecation target
This does actually working suprisingly enough, applying deprecation to all methods in the impl block
r? `@jdonszelmann`
Hard-code `char::is_control`
Split off from https://github.com/rust-lang/rust/pull/145219
According to
https://www.unicode.org/policies/stability_policy.html#Property_Value, the set of codepoints in `Cc` will never change. So we can hard-code the patterns to match against instead of using a table.
This doesn't change the generated assembly, since the lookup table is small enough that[ LLVM is able to inline the whole search](https://godbolt.org/z/bG8dM37YG). But this does reduce the chance of regressions if LLVM's heuristics change in the future, and means less generated Rust code checked in to `unicode-data.rs`.
