fix(lexer): Don't require frontmatters to be escaped with indented fences
The RFC only limits hyphens at the beginning of lines and not if they are indented or embedded in other content.
Sticking to that approach was confirmed by the T-lang liason at https://github.com/rust-lang/rust/issues/141367#issuecomment-3202217544
There is a regression in error message quality which I'm leaving for someone if they feel this needs improving.
Tracking issue: rust-lang/rust#136889Fixesrust-lang/rust#141367
coverage: Build an "expansion tree" and use it to unexpand raw spans
Historically and currently, coverage instrumentation assumes that all of a function's spans are in the same file and have the same syntax context. The spans extracted directly from MIR don't satisfy that assumption, so there is an “unexpansion” step that walks up each span's expansion-call-site tree to find a suitable span in the same context as the function's body span.
(That unexpansion step is what allows us to have somewhat reasonable coverage instrumentation for macros like `println!`, and for syntax like `for` and `?` that undergo desugaring expansion.)
The current unexpansion code mostly works fine in that “flat” single-file single-context world. But it's not suitable for incremental work towards proper expansion-aware coverage instrumentation, which would allow a function's coverage spans to encompass multiple expansion contexts and multiple files.
This PR therefore replaces the current unexpansion code with a more sophisticated system that uses the raw MIR spans to reconstruct an “expansion tree”, and then uses that tree to help perform most of the unexpansion work.
Building the tree is “overkill” for current unexpansion needs (though it does give some minor edge-case improvements), but my hope is that having the explicit tree available will be a big help when taking the next steps towards proper expansion-region support.
dedup recip, powi, to_degrees, and to_radians float tests
Deduplicates recip, powi, to_degrees, and to_radians float tests.
I had to fiddle and slightly increase the tolerances for a few comparisons, so maybe not all of the tests are worth deduplicating.
Part of rust-lang/rust#141726.
Best reviewed commit-by-commit.
r? `@tgross35`
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`.
The tool wasn't useful for anything, it was only built as a part of the test, but we can just use `cargo test` and `cargo run` in the test, no need to (pre-)build the tool itself.
Stuart Cook