compiletest: Run the `lldb_batchmode.py` script in LLDB's embedded Python
Historically, LLDB debuginfo tests have used a Python script to control LLDB via its Python API, instead of invoking the `lldb` command directly.
Unfortunately, this requires us to find and use a version of Python that is compatible with LLDB's Python bindings.
However, it turns out that there is a simpler way to find a compatible Python interpreter: use the one that is embedded in LLDB itself, via the `script` command.
Rollup of 4 pull requests
Successful merges:
- rust-lang/rust#148248 (Constify `ControlFlow` methods without unstable bounds)
- rust-lang/rust#148285 (Constify `ControlFlow` methods with unstable bounds)
- rust-lang/rust#148510 (compiletest: Do the known-directives check only once, and improve its error message)
- rust-lang/rust#148655 (Fix invalid macro tag generation for keywords which can be followed by values)
r? `@ghost`
`@rustbot` modify labels: rollup
compiletest: Do the known-directives check only once, and improve its error message
This PR is a combination of three changes:
- Store the list of known directives in a set, so that checking a directive name doesn't require a linear scan
- Extract the known-directives check out of `iter_directives` and do it only once, instead of multiple times per file
- Improve the error message for unknown directives, [as requested on Zulip](https://rust-lang.zulipchat.com/#narrow/channel/326414-t-infra.2Fbootstrap/topic/Compiletest.20directive.20parsing.20error/with/553598083)
The change to error messages is fused with the extraction, since doing it independently would have been more awkward.
---
## Before
```text
Testing stage1 with compiletest suite=coverage mode=coverage-map (aarch64-apple-darwin)
errors encountered during EarlyProps parsing: /Users/stuart/Dev/rust/rust/tests/coverage/trivial.rs
2025-11-05T01:55:46.440012Z ERROR compiletest::directives: /Users/stuart/Dev/rust/rust/tests/coverage/trivial.rs:2: detected unknown compiletest test directive `add-core-stubs`
thread '<unnamed>' (36268582) panicked at src/tools/compiletest/src/directives.rs:72:13:
errors encountered during EarlyProps parsing
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
```
## After
```text
Testing stage1 with compiletest suite=coverage mode=coverage-map (aarch64-apple-darwin)
thread '<unnamed>' (36270772) panicked at src/tools/compiletest/src/lib.rs:876:9:
directives check failed:
ERROR: unknown compiletest directive `add-core-stubs` at /Users/stuart/Dev/rust/rust/tests/coverage/trivial.rs:2
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
```
Constify `ControlFlow` methods with unstable bounds
Feature: `const_control_flow`
Tracking issue: rust-lang/rust#148739
This PR constifies the methods on `ControlFlow` with a dependency on rust-lang/rust#143874.
Constify `ControlFlow` methods without unstable bounds
Feature: `min_const_control_flow`
Tracking issue: rust-lang/rust#148738
This PR constifies some of the methods on `ControlFlow`.
Implement the MCP 932: Promote riscv64a23-unknown-linux-gnu to Tier 2
Implement the [MCP 932](https://github.com/rust-lang/compiler-team/issues/932): Promote riscv64a23-unknown-linux-gnu to Tier 2 without host tools.
Closesrust-lang/rust#148353.
Changes:
- Update target tier from 3 to 2 in target specification
- Update platform documentation
- Add CI/CD support for automatic building and distribution via rustup
r? jieyouxu
cc `@davidtwco` `@Noratrieb`
Fix typo in unstable-book link
This prevented the links from being rendered. Sorry for not noticing this before my changes were merged yesterday.
Introduced in https://github.com/rust-lang/rust/pull/147935
cc ``@petrochenkov``
tidy: Don't bypass stderr output capture in unit tests
In unit tests, writes to stderr that don't use `eprint!` or `eprintln!` will not be captured, and instead interfere with test harness output, making it unreadable.
<details>
<summary><b>Detailed before/after</b></summary>
## Before
```text
$ x test tidyselftest --no-doc
Building bootstrap
Finished `dev` profile [unoptimized] target(s) in 0.03s
Testing stage1 tidy (aarch64-apple-darwin)
Compiling tidy v0.1.0 (/Users/stuart/Dev/rust/rust/src/tools/tidy)
Finished `release` profile [optimized + debuginfo] target(s) in 0.23s
Running unittests src/lib.rs (build/aarch64-apple-darwin/bootstrap-tools/aarch64-apple-darwin/release/deps/tidy-c33a0cc08cf46c66)
running 20 tests
tidy [alphabetical-test]: bad:3 found `tidy-alphabetical-start` expecting `tidy-alphabetical-end`
tidy [alphabetical-test]: FAIL
tidy [alphabetical-test]: bad: reached end of file expecting `tidy-alphabetical-end`tidy [alphabetical-test]: bad:4: line not in alphabetical order
tidy [alphabetical-test]: bad:5 found `tidy-alphabetical-end` expecting `tidy-alphabetical-start`
tidy [alphabetical-test]: FAIL
tidy [alphabetical-test]: FAIL
tidy [alphabetical-test].: tidy [alphabetical-test...bad:4: line not in alphabetical order..]: tidy [alphabetical-test]: ..
bad:7: line not in alphabetical order
tidy [tidy [bad:2 found `tidy-alphabetical-end` expecting `tidy-alphabetical-start`
alphabetical-testtidy [tidy [alphabetical-test]: bad:4: line not in alphabetical order
.tidy [alphabetical-test]..]alphabetical-testtidy []: bad:4: line not in alphabetical orderalphabetical-testalphabetical-test]: tidy [FAILalphabetical-test
]: FAIL
]: FAIL
: FAIL
: bad:4: line not in alphabetical order
tidy [alphabetical-test]: FAIL
tidy [.alphabetical-test]: FAIL
.tidy [alphabetical-test]: FAIL
..tidy [alphabetical-test]: bad:3: line not in alphabetical order
tidy [alphabetical-test]: FAIL
tidy [alphabetical-test]: bad:3: line not in alphabetical order
tidy [alphabetical-test]: FAIL
.....
test result: ok. 20 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 1.01ms
Running unittests src/main.rs (build/aarch64-apple-darwin/bootstrap-tools/aarch64-apple-darwin/release/deps/rust_tidy-25232a69af4dd751)
running 0 tests
test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 26.88µs
finished in 0.255 seconds
Build completed successfully in 0:00:00
```
## After
```text
$ x test tidyselftest --no-doc
Building bootstrap
Finished `dev` profile [unoptimized] target(s) in 0.03s
Testing stage1 tidy (aarch64-apple-darwin)
Compiling tidy v0.1.0 (/Users/stuart/Dev/rust/rust/src/tools/tidy)
Finished `release` profile [optimized + debuginfo] target(s) in 1.74s
Running unittests src/lib.rs (build/aarch64-apple-darwin/bootstrap-tools/aarch64-apple-darwin/release/deps/tidy-c33a0cc08cf46c66)
running 20 tests
....................
test result: ok. 20 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 1.35ms
Running unittests src/main.rs (build/aarch64-apple-darwin/bootstrap-tools/aarch64-apple-darwin/release/deps/rust_tidy-25232a69af4dd751)
running 0 tests
test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 27.17µs
finished in 1.764 seconds
Build completed successfully in 0:00:02
```
</details>
bootstrap: Render doctest timing reports as text, not JSON
These doctest timing reports were added to libtest/rustdoc in https://github.com/rust-lang/rust/pull/144909, but bootstrap's custom test-output renderer wasn't taught about them, so they were being printed as raw JSON instead.
Before:
```text
{ "type": "report", "total_time": 0.738403958, "compilation_time": 0.731513292 }
```
After:
```text
all doctests ran in 0.73s; merged doctests compilation took 0.72s
```
<details>
<summary><b>Detailed before/after in context</b></summary>
## Before
```text
$ x test rustc_mir_transform --doc
Building bootstrap
Finished `dev` profile [unoptimized] target(s) in 0.03s
Testing stage1 {rustc_mir_transform} (aarch64-apple-darwin)
Finished `release` profile [optimized + debuginfo] target(s) in 0.12s
Doc-tests rustc_mir_transform
running 19 tests
iiiiiiiiiiii.......
test result: ok. 7 passed; 0 failed; 12 ignored; 0 measured; 0 filtered out; finished in 3.28ms
running 7 tests
iiiiiii
test result: ok. 0 passed; 0 failed; 7 ignored; 0 measured; 0 filtered out; finished in 403.67µs
{ "type": "report", "total_time": 0.738403958, "compilation_time": 0.731513292 }
finished in 1.505 seconds
Build completed successfully in 0:00:01
```
## After
```text
$ x test rustc_mir_transform --doc
Building bootstrap
Finished `dev` profile [unoptimized] target(s) in 0.03s
Testing stage1 {rustc_mir_transform} (aarch64-apple-darwin)
Finished `release` profile [optimized + debuginfo] target(s) in 0.12s
Doc-tests rustc_mir_transform
running 19 tests
iiiiiiiiiiii.......
test result: ok. 7 passed; 0 failed; 12 ignored; 0 measured; 0 filtered out; finished in 3.12ms
running 7 tests
iiiiiii
test result: ok. 0 passed; 0 failed; 7 ignored; 0 measured; 0 filtered out; finished in 395.67µs
all doctests ran in 0.73s; merged doctests compilation took 0.72s
finished in 1.493 seconds
Build completed successfully in 0:00:01
```
</details>
mgca: Finish implementation of `#[type_const]`
tracking issue: rust-lang/rust#132980fixesrust-lang/rust#140729fixesrust-lang/rust#140860
- **Fix `#[type_const]` attribute placement validation**
- **Perform WF-checking on type_const RHS's**
- **Check type_const type is ConstParamTy_ and that RHS matches it**
- **Check that impls of `#[type_const]` consts also have the attr**
r? ```@BoxyUwU```
fix: disable self-contained linker when bootstrap-override-lld is set
Part of rust-lang/rust#148708.
Makes `rust.bootstrap-override-lld` set to `true` or `"external"` disable self-contained linker — actually using linker from one's system.
Remove `#[const_trait]`
Remove `#[const_trait]` since we now have `const trait`. Update all structured diagnostics that still suggested the attribute.
r? ```@rust-lang/project-const-traits```
Encode cfg trace, not its early counterpart to fix cross-crate `doc(auto_cfg)`
Fixesrust-lang/rust#141301.
<details><summary>Rambling about <code>target_feature</code> which I didn't touch here</summary>
Regarding https://github.com/rust-lang/rust/issues/141301#issuecomment-3390100259 (`#[target_feature(enable = …)]` on inlined cross-crate re-exports), it has the same underlying cause (namely, we neither encode `target_feature` nor `AttributeKind::TargetFeature` in the crate metadata). However, I didn't make that change because I first want to experiment with querying `TyCtxt::codegen_fn_attrs` in rustdoc instead which already works cross-crate (and also use to it for reconstructing `no_mangle`, `export_name`, `link_section` to avoid encoding these attributes unnecessarily (basically reverting rust-lang/rust#144050) as suggested in https://github.com/rust-lang/rust/issues/144004#issuecomment-3077725837).
</details>
r? GuillaumeGomez
In unit tests, writes to stderr that don't use `eprint!` or `eprintln!` will
not be captured, and instead interfere with test harness output, making it
unreadable.
