Move metadata symbol export from exported_non_generic_symbols to exported_symbols
The metadata symbol must not be encoded in the crate metadata, and must be exported from proc-macros. Handling the export of the metadata symbol in exported_symbols handles both things at once without requiring manual fixups elsewhere.
Add a lot of NLL `known-bug` tests
r? ``@jackh726``
As requested in https://github.com/rust-lang/rust/pull/143093#pullrequestreview-3058256280 this extracts most tests from that PR and expands upon them as described.
The handful of linked-list cursor-like tests will also turn into polonius=next known-bugs in rust-lang/rust#143093 where the behavior w/r/t kills changes of course.
move `type_check` out of `compute_regions`
A step towards rust-lang/rust#139587. I don't think there's a clear reason for why MIR type check should be in `compute_regions` and this simplifies future PRs here.
coverage: Remove all unstable support for MC/DC instrumentation
Preliminary support for a partial implementation of “Modified Condition/Decision Coverage” instrumentation was added behind the unstable flag `-Zcoverage-options=mcdc` in 2024. These are the most substantial PRs involved:
- rust-lang/rust#123409
- rust-lang/rust#126733
At the time, I accepted these PRs with relatively modest scrutiny, because I did not want to stand in the way of independent work on MC/DC instrumentation. My hope was that ongoing work by interested contributors would lead to the code becoming clearer and more maintainable over time.
---
However, that MC/DC code has proven itself to be a major burden on overall maintenance of coverage instrumentation, and a major obstacle to other planned improvements, such as internal changes needed for proper support of macro expansion regions.
I have also become reluctant to accept any further MC/DC-related changes that would increase this burden.
That tension has resulted in an unhappy impasse. On one hand, the present MC/DC implementation is not yet complete, and shows little sign of being complete at an acceptable level of code quality in the foreseeable future. On the other hand, the continued existence of this partial MC/DC implementation is imposing serious maintenance burdens on every other aspect of coverage instrumentation, and is preventing some of the very improvements that would make it easier to accept expanded MC/DC support in the future.
While I know this will be disappointing to some, I think the healthy way forward is accept that I made the wrong call in accepting the current implementation, and to remove it entirely from the compiler.
[win][arm64ec] Fix msvc-wholearchive for Arm64EC
`msvc-wholearchive` was failing on Arm64EC Windows as it requires the `/MACHINE:ARM64EC` flag to be passed to the MSVC linker.
This required splitting the `extra_c_flags` function into a new `extra_linker_flags` function as `/MACHINE:ARM64EC` is not a valid argument to be passed to the MSVC Compiler (instead, `/arm64EC` should be used).
Add support for `ty::Instance` path shortening in diagnostics
Make `ty::Instance` able to use `short_string` and usable in structured errors directly. Remove some ad-hoc type shortening logic.
Resolver: introduce a conditionally mutable Resolver for (non-)speculative resolution.
This pr introduces a `CmResolver`, a wrapper around the main resolver which gives out mutable access given a condition.
`CmResolver` only allows mutation when we’re not in speculative import resolution. This ensures we can’t accidentally mutate the resolver during this process, which is important as we move towards a batched resolution algorithm.
This also changes functions that are used during speculative import resolution to take a `CmResolver` instead of a `&mut Resolver`.
Also introduces a new kind of "smart pointer" which has the behaviour described above:
```rust
/// A wrapper around a mutable reference that conditionally allows mutable access.
pub(crate) struct RefOrMut<'a, T> {
p: &'a mut T,
mutable: bool,
}
type CmResolver<'r, 'ra, 'tcx> = RefOrMut<'r, Resolver<'ra, 'tcx>>;
```
r? petrochenkov
Add new `test::print_merged_doctests_times` used by rustdoc to display more detailed time information
This PR is the first commit of https://github.com/rust-lang/rust/pull/144908. Sadly, it seems like we can't do all of it at once...
r? ``@Amanieu``
Print CGU reuse statistics in `-Zprint-mono-items`
I'm trying to expose more information about incremental profiling from rustc (https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/Profiling.2Fanalysis.20of.20incremental.20builds/with/531383501). One of the things that would be quite useful to expose is the CGU reuse state, so that when you do a rebuild, you can see all the CGUs (and all the functions) that had to be recompiled.
Currently, we have (AFAIK) two ways of outputting monomorphization statistics:
1) `-Zdump-mono-stats` outputs statistics about number of instantiations and expected compilation cost of individual functions in the local crate being compiled. It can be outputted either as Markdown or JSON.
2) `-Zprint-mono-items` outputs a pair (item, CGU) for each monomorphized item.
I was thinking about recording CGU statistics in the self-profile output, but I realized that as a simpler step, we could just add CGU reuse data to `-Zprint-mono-items`, as an additional output. That is what this PR does.
Streamline config in bootstrap
This PR restructures the config module to improve readability and debuggability. It also aims to eliminate as many invariants as possible. Best reviewed commit by commit.
r? `````@Kobzol`````
[codegen] assume the tag, not the relative discriminant
Address the issue mentioned in <https://github.com/llvm/llvm-project/issues/134024#issuecomment-3131782555> by changing discriminant calculation to `assume` on the originally-loaded `tag`, rather than on `cast(tag)-OFFSET`.
The previous way does make the *purpose* of the assume clearer, IMHO, since you see `assume(x != 4); if p { x } else { 4 }`, but doing it this way instead means that the `add`s optimize away in LLVM21, which is more important. And this new way is still easily thought of as being like metadata on the load saying specifically which value is impossible.
Demo of the LLVM20 vs LLVM21 difference: <https://llvm.godbolt.org/z/n54x5Mq1T>
r? ``@nikic``
`tests/ui/issues/`: The Issues Strike Back [3/N]
Some `tests/ui/issues/` housekeeping, to trim down number of tests directly under `tests/ui/issues/`. Part of https://github.com/rust-lang/rust/issues/133895.
r? ```@jieyouxu```
The metadata symbol must not be encoded in the crate metadata, and must
be exported from proc-macros. Handling the export of the metadata symbol
in exported_symbols handles both things at once without requiring manual
fixups elsewhere.
The implementation of the linkage attribute inside extern blocks defines
symbols starting with _rust_extern_with_linkage_. If someone tries to
also define this symbol you will get a symbol conflict or even an ICE.
By adding an unpredictable component to the symbol name, this becomes
less of an issue.
bump bootstrap compiler to 1.90 beta
There were significantly less `cfg(bootstrap)` and `cfg(not(bootstrap))` this release. Presumably due to the fact that we change the bootstrap stage orderings to reduce the need for them and it was successful 🙏
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/).
