Reimplement `print_region` in `type_name.rs`.
Broken by rust-lang/rust#144776; this is reachable after all.
Fixesrust-lang/rust#144994.
The commit also adds a lot more cases to the `type-name-basic.rs`, because it's currently very anaemic. This includes some cases where region omission does very badly; these are marked with FIXME.
r? `@fmease`
Update books
## rust-lang/book
5 commits in b2d1a0821e12a676b496d61891b8e3d374a8e832..3e9dc46aa563ca0c53ec826c41b05f10c5915925
2025-08-02 01:33:29 UTC to 2025-07-14 21:23:38 UTC
- Appendix B and Appendix D from tech review (rust-lang/book#4466)
- Chapter 21 from tech review (rust-lang/book#4464)
- Chapter 20 from tech review (rust-lang/book#4460)
- Chapter 19 from tech review (rust-lang/book#4446)
- Chapter 18 from tech review (rust-lang/book#4445)
## rust-lang/reference
12 commits in 1f45bd41fa6c17b7c048ed6bfe5f168c4311206a..1be151c051a082b542548c62cafbcb055fa8944f
2025-08-05 19:51:40 UTC to 2025-07-14 19:49:01 UTC
- Fix build output directory in README (rust-lang/reference#1950)
- Update `link_name` to use the attribute template (rust-lang/reference#1896)
- Update `no_link` to use the attribute template (rust-lang/reference#1898)
- Update `proc_macro_derive` to use the attribute template (rust-lang/reference#1888)
- Update `automatically_derived` to use the attribute template (rust-lang/reference#1884)
- Update `derive` to use the attribute template (rust-lang/reference#1883)
- Fix and clarify CR LF normalization and CR in string literals (rust-lang/reference#1944)
- glossary.md: tweak description of "dispatch" (rust-lang/reference#1938)
- add missing id, r[asm.operand-type.supported-operands.const] (rust-lang/reference#1939)
- &str and &[u8] have the same layout (rust-lang/reference#1848)
- Rename and rewrite the "question mark operator" (rust-lang/reference#1931)
- Change "allocated object" to "allocation". (rust-lang/reference#1930)
## rust-lang/rust-by-example
3 commits in e386be5f44af711854207c11fdd61bb576270b04..bd1279cdc9865bfff605e741fb76a0b2f07314a7
2025-08-04 13:41:04 UTC to 2025-08-02 15:41:59 UTC
- Improve the activity instructions in `print_display` (rust-lang/rust-by-example#1948)
- Minor fixes (whitespace, typo, i32->u32) (rust-lang/rust-by-example#1947)
- Document drawbacks of alternatives to match binding (rust-lang/rust-by-example#1946)
bootstrap: refactor mingw dist and fix gnullvm
Fixes https://github.com/rust-lang/rust/issues/144533
The first two commits are NFC and only clean up the code, paving the way for the third commit. That said, I think they are worthwhile even without that fix - reusing the same function for two different outcomes was confusing.
The third commit is the fix for https://github.com/rust-lang/rust/issues/144533, but due to the cross-compilation dance it requires a workaround to find the DLL since that logic really was meant only for Windows builders. That workaround is short-lived and will be removed as soon as gnullvm bootstraps itself.
Additional tce tests
r? `@oli-obk`
Adds known-bug tests for LLVM emissions regarding indirect operands for TCE. Also includes a test, `indexer.rs`, referring to function_table behavior described by the RFC.
Depends on rust-lang/rust#144232Closesrust-lang/rust#144293
Allow `cargo fix` to partially apply `mismatched_lifetime_syntaxes`
Workaround for https://github.com/rust-lang/rust/issues/144588#issuecomment-3128445308
Not all suggestions have to be hidden from `cargo fix`, only redundant ones. The redundant ones are already hidden from the user, so the same `tool_only` flag can be used to hide them from `cargo fix`. This way `cargo fix` will be able to correctly apply the fixes, and will apply only the fix that the compiler visibly suggests to the user.
Address libunwind.a inconsistency issues in the bootstrap program
We noticed when building rustc multiple time in a roll, some files will not be consistent across the build despite the fact that they are built from same source under the same environment. This patch addresses the inconsistency issue we found on libunwind.a, by sorting the order of the files passed to the linker.
Upgrade semicolon_in_expressions_from_macros from warn to deny
This is already warn-by-default, and a future compatibility warning (FCW) that warns in dependencies. Upgrade it to deny-by-default, as the next step towards hard error.
Per https://github.com/rust-lang/rust/issues/79813#issuecomment-3109105631
Stabilize const TypeId::of
fixesrust-lang/rust#77125
# Stabilization report for `const_type_id`
## General design
### What is the RFC for this feature and what changes have occurred to the user-facing design since the RFC was finalized?
N/A the constness was never RFCed
### What behavior are we committing to that has been controversial? Summarize the major arguments pro/con.
`const_type_id` was kept unstable because we are currently unable to stabilize the `PartialEq` impl for it (in const contexts), so we feared people would transmute the type id to an integer and compare that integer.
### Are there extensions to this feature that remain unstable? How do we know that we are not accidentally committing to those?
`TypeId::eq` is not const at this time, and will only become const once const traits are stable.
## Has a Call for Testing period been conducted? If so, what feedback was received?
This feature has been unstable for a long time, and most people just worked around it on stable by storing a pointer to `TypeId::of` and calling that at "runtime" (usually LLVM devirtualized the function pointer and inlined the call so there was no real performance difference).
A lot of people seem to be using the `const_type_id` feature gate (600 results for the feature gate on github: https://github.com/search?q=%22%23%21%5Bfeature%28const_type_id%29%5D%22&type=code)
We have had very little feedback except desire for stabilization being expressed.
## Implementation quality
Until these three PRs
* https://github.com/rust-lang/rust/pull/142789
* https://github.com/rust-lang/rust/pull/143696
* https://github.com/rust-lang/rust/pull/143736
there was no difference between the const eval feature and the runtime feature except that we prevented you from using `TypeId::of` at compile-time. These three recent PRs have hardened the internals of `TypeId`:
* it now contains an array of pointers instead of integers
* these pointers at compile-time (and in miri) contain provenance that makes them unique and prevents inspection. Both miri and CTFE will in fact error if you mess with the bits or the provenance of the pointers in any way and then try to use the `TypeId` for an equality check. This also guards against creating values of type `TypeId` by any means other than `TypeId::of`
### Summarize the major parts of the implementation and provide links into the code (or to PRs)
N/A see above
### Summarize existing test coverage of this feature
Since we are not stabilizing any operations on `TypeId` except for creating `TypeId`s, the test coverage of the runtime implementation of `TypeId` covers all the interesting use cases not in the list below
#### Hardening against transmutes
* https://github.com/rust-lang/rust/blob/master/tests/ui/consts/const_transmute_type_id.rs
* https://github.com/rust-lang/rust/blob/master/tests/ui/consts/const_transmute_type_id2.rs
* https://github.com/rust-lang/rust/blob/master/tests/ui/consts/const_transmute_type_id3.rs
* https://github.com/rust-lang/rust/blob/master/tests/ui/consts/const_transmute_type_id4.rs
* https://github.com/rust-lang/rust/blob/master/tests/ui/consts/const_transmute_type_id5.rs
#### TypeId::eq is still unstable
* https://github.com/rust-lang/rust/blob/master/tests/ui/consts/const_cmp_type_id.rs
### What outstanding bugs in the issue tracker involve this feature? Are they stabilization-blocking?
https://github.com/rust-lang/rust/issues/129014 is still unresolved, but it affects more the runtime version of `TypeId` than the compile-time.
### What FIXMEs are still in the code for that feature and why is it ok to leave them there?
none
### Summarize contributors to the feature by name for recognition and assuredness that people involved in the feature agree with stabilization
* `@eddyb`
* `@RalfJung`
### Which tools need to be adjusted to support this feature. Has this work been done?
N/A
## Type system and execution rules
### What compilation-time checks are done that are needed to prevent undefined behavior?
Already covered above. Transmuting types with private fields to expose those fields has always been library UB, but for the specific case of `TypeId` CTFE and Miri will detect it if that is done in any way other than for reconstructing the exact same `TypeId` in another location.
### Does the feature's implementation need checks to prevent UB or is it sound by default and needs opt in in places to perform the dangerous/unsafe operations? If it is not sound by default, what is the rationale?
N/A
### Can users use this feature to introduce undefined behavior, or use this feature to break the abstraction of Rust and expose the underlying assembly-level implementation? (Describe.)
N/A
### What updates are needed to the reference/specification? (link to PRs when they exist)
Nothing more than what needs to exist for `TypeId` already.
## Common interactions
### Does this feature introduce new expressions and can they produce temporaries? What are the lifetimes of those temporaries?
N/A
### What other unstable features may be exposed by this feature?
N/A
Miri: non-deterministic floating point operations in `foreign_items`
Part of [rust-lang/miri/#3555](https://github.com/rust-lang/miri/issues/3555#issue-2278914000), this pr does the `foreign_items` work.
Some things have changed since rust-lang/rust#138062 and rust-lang/rust#142514. I moved the "helpers" used for creating fixed outputs and clamping operations to their defined ranges to `math.rs`. These are now also extended to handle the floating-point operations in `foreign_items`. Tests in `miri/tests/float.rs` were changed/added.
Failing tests in `std` were extracted, run under miri with `-Zmiri-many-seeds=0..1000` and changed accordingly. Double checked with `-Zmiri-many-seeds`.
I noticed that the C standard doesn't specify the output ranges for all of its mathematical operations; it just specifies them as:
```
Returns
The sinh functions return sinh x.
```
So I used [Wolfram|Alpha](https://www.wolframalpha.com/).
emit `StorageLive` and schedule `StorageDead` for `let`-`else`'s bindings after matching
This PR removes special handling of `let`-`else`, so that `StorageLive`s are emitted and `StorageDead`s are scheduled only after pattern-matching has succeeded. This means `StorageDead`s will no longer appear for all of its bindings on the `else` branch (because they're not live yet) and its drops&`StorageDead`s will happen together like they do elsewhere, rather than having all drops first, then all `StorageDead`s.
This fixesrust-lang/rust#142056, and is therefore a breaking change. I believe it'll need a crater run and a T-lang nomination/fcp thereafter. Specifically, this makes drop-checking slightly more restrictive for `let`-`else` to match the behavior of other variable binding forms. An alternative approach could be to change the relative order of drops and `StorageDead`s for other binding forms to make drop-checking more permissive, but making that consistent would be a significantly more involved change.
r? mir
cc `````@dingxiangfei2009`````
`````@rustbot````` label +T-lang +needs-crater
Tweak auto trait errors
Make suggestions to remove params and super traits verbose and make spans more accurate.
```
error[E0567]: auto traits cannot have generic parameters
--> $DIR/auto-trait-validation.rs:6:19
|
LL | auto trait Generic<T> {}
| -------^^^
| |
| auto trait cannot have generic parameters
error[E0568]: auto traits cannot have super traits or lifetime bounds
--> $DIR/auto-trait-validation.rs:8:20
|
LL | auto trait Bound : Copy {}
| ----- ^^^^
| |
| auto traits cannot have super traits or lifetime bounds
```
```
error[E0380]: auto traits cannot have associated items
--> $DIR/issue-23080.rs:5:8
|
LL | unsafe auto trait Trait {
| ----- auto traits cannot have associated items
LL | fn method(&self) {
| ^^^^^^
```
Simplify dead code lint
This PR scratches a few itches I had when looking at that code.
The perf improvement comes from keeping the `scanned` set through several marking phases. This pretty much divides by 2 the number of HIR traversals.
Consolidate staging for `rustc_private` tools
This PR continues bootstrap refactoring, this time by consolidating staging for `Mode::ToolRustc` tools. This refactoring was in the critical path of refactoring `test`/`dist`/`clippy`/`doc` steps, and getting rid of the rmeta/rlib sysroot copy, because tools are pervasive and they are being used for a lot of things in bootstrap.
The main idea is to explicitly model the fact that a stage N `Mode::ToolRustc` tool always works with two different compilers:
- Stage N-1 rustc (`build_compiler`) builds stage N rustc (`target_compiler`)
- Rlib artifacts from stage N rustc are copied to the sysroot of stage N-1 rustc
- Stage N-1 rustc builds the (stage N) tool itself, the tool links to the rlib artifacts of the stage N rustc
Before, the code often used `compiler`, which meant sometimes the build compiler, sometimes the target compiler, and sometimes neither (looking at you, `download-rustc`). This is especially annoying when you get to a situation where you have an install step that invokes a dist step that invokes a tool build step, where *some* compiler is being propagated through, without it being clear what does that compiler represent. This refactoring hopefully makes that clearer and more explicit. It also gets rid of a few `builder.ensure(Rustc(...))` calls within bootstrap, which is always nice.
`Rustdoc` needs to be handled a bit specially, because it acts as a compiler itself, I documented that in the changes.
It wasn't practical to do these refactorings in multiple PRs, so I did it all in one PR. The meat of the change is 9ee6d1c1ed112c3dcfb5684b33772b136df0dca3.
I tested manually that `x build rustdoc` and `x build miri` still works even with `download-rustc`, although I cannot promise any extra support for `download-rustc`, IMO we will just have to reimplement it from scratch in a different way.
As usually, I did some drive-by refactorings to bootstrap, trying to document and clarify things, add more step metadata and tests.
Since these changes broke Cargo, which was incorrectly using `Mode::ToolRustc`, I also changed cargo to `ToolTarget` in this PR.
Best reviewed commit-by-commit (note that I renamed `link_compiler` to `target_compiler`, in accordance to the rest of bootstrap, in the last commit).
r? `@jieyouxu`
try-job: x86_64-gnu-aux
try-job: x86_64-msvc-ext1
Delete `tests/ui/threads-sendsync/tcp-stress.rs`
This stress test was originally introduced in 65cca4bd3fa0abe1000662014b3e3ea1420728f5 to detect a UAF in `libuv` (see rust-lang/rust#12823), but we no longer use `libuv`, so remove this test as it no longer serves its original purpose, and is causing flaky timeout failures.
Closesrust-lang/rust#144878 (by removing the test).
r? libs
Rehome 21 `tests/ui/issues/` tests to other subdirectories under `tests/ui/`
rust-lang/rust#143902 divided into smaller, easier to review chunks.
Part of rust-lang/rust#133895
Methodology:
1. Refer to the previously written `tests/ui/SUMMARY.md`
2. Find an appropriate category for the test, using the original issue thread and the test contents.
3. Add the issue URL at the bottom (not at the top, as that would mess up stderr line numbers)
4. Rename the tests to make their purpose clearer
Inspired by the methodology that ``@Kivooeo`` was using.
r? ``@jieyouxu``
