Reflection MVP
I am opening this PR for discussion about the general design we should start out with, as there are various options (that are not too hard to transition between each other, so we should totally just pick one and go with it and reiterate later)
r? @scottmcm and @joshtriplett
project goal issue: https://github.com/rust-lang/rust-project-goals/issues/406
tracking issue: https://github.com/rust-lang/rust/issues/146922
The design currently implemented by this PR is
* `TypeId::info` (method, usually used as `id.info()` returns a `Type` struct
* the `Type` struct has fields that contain information about the type
* the most notable field is `kind`, which is a non-exhaustive enum over all possible type kinds and their specific information. So it has a `Tuple(Tuple)` variant, where the only field is a `Tuple` struct type that contains more information (The list of type ids that make up the tuple).
* To get nested type information (like the type of fields) you need to call `TypeId::info` again.
* There is only one language intrinsic to go from `TypeId` to `Type`, and it does all the work
An alternative design could be
* Lots of small methods (each backed by an intrinsic) on `TypeId` that return all the individual information pieces (size, align, number of fields, number of variants, ...)
* This is how C++ does it (see https://lemire.me/blog/2025/06/22/c26-will-include-compile-time-reflection-why-should-you-care/ and https://isocpp.org/files/papers/P2996R13.html#member-queries)
* Advantage: you only get the information you ask for, so it's probably cheaper if you get just one piece of information for lots of types (e.g. reimplementing size_of in terms of `TypeId::info` is likely expensive and wasteful)
* Disadvantage: lots of method calling (and `Option` return types, or "general" methods like `num_fields` returning 0 for primitives) instead of matching and field accesses
* a crates.io crate could implement `TypeId::info` in terms of this design
The backing implementation is modular enough that switching from one to the other is probably not an issue, and the alternative design could be easier for the CTFE engine's implementation, just not as nice to use for end users (without crates wrapping the logic)
One wart of this design that I'm fixing in separate branches is that `TypeId::info` will panic if used at runtime, while it should be uncallable
resolve: Factor out and document the glob binding overwriting logic
Also, avoid creating fresh name declarations and overwriting declarations in modules to update some fields in `DeclData`, when possible.
Instead, change the fields directly in `DeclData` using cells.
Unblocks https://github.com/rust-lang/rust/pull/149195.
Fix for ICE: eii: fn / macro rules None in find_attr()
Closesrust-lang/rust#149981
This used to ICE:
```rust
macro_rules! foo_impl {}
#[eii]
fn foo_impl() {}
```
`#[eii]` generates a macro (called `foo_impl`) and a default impl. So the partial expansion used to roughly look like the following:
```rust
macro_rules! foo_impl {} // actually resolves here
extern "Rust" {
fn foo_impl();
}
#[eii_extern_target(foo_impl)]
macro foo_impl {
() => {};
}
const _: () = {
#[implements_eii(foo_impl)] // assumed to name resolve to the macro v2 above
fn foo_impl() {}
};
```
Now, shadowing rules for macrov2 and macrov1 are super weird! Take a look at this: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2024&gist=23f21421921360478b0ec0276711ad36
So instead of resolving to the macrov2, we resolve the macrov1 named the same thing.
A regression test was added to this, and some span_delayed_bugs were added to make sure we catch this in the right places. But that didn't fix the root cause.
To make sure this simply cannot happen again, I made it so that we don't even need to do a name resolution for the default. In other words, the new partial expansion looks more like:
```rust
macro_rules! foo_impl {}
extern "Rust" {
fn foo_impl(); // resolves to here now!!!
}
#[eii_extern_target(foo_impl)]
macro foo_impl {
() => {};
}
const _: () = {
#[implements_eii(known_extern_target=foo_impl)] // still name resolved, but directly to the foreign function.
fn foo_impl() {}
};
```
The reason this helps is that name resolution for non-macros is much more predictable. It's not possible to have two functions like that with the same name in scope.
We used to key externally implementable items off of the defid of the macro, but now the unique identifier is the foreign function's defid which seems much more sane.
Finally, I lied a tiny bit because the above partial expansion doesn't actually work.
```rust
extern "Rust" {
fn foo_impl(); // not to here
}
const _: () = {
#[implements_eii(known_extern_target=foo_impl)] // actually resolves to this function itself
fn foo_impl() {} // <--- so to here
};
```
So the last few commits change the expansion to actually be this:
```rust
macro_rules! foo_impl {}
extern "Rust" {
fn foo_impl(); // resolves to here now!!!
}
#[eii_extern_target(foo_impl)]
macro foo_impl {
() => {};
}
const _: () = {
mod dflt { // necessary, otherwise `super` doesn't work
use super::*;
#[implements_eii(known_extern_target=super::foo_impl)] // now resolves to outside the `dflt` module, so the foreign item.
fn foo_impl() {}
}
};
```
I apologize to whoever needs to review this, this is very subtle and I hope this makes it clear enough 😭.
Rollup of 11 pull requests
Successful merges:
- rust-lang/rust#150272 (docs(core): update `find()` and `rfind()` examples)
- rust-lang/rust#150385 (fix `Expr::can_have_side_effects` for `[x; N]` style array literal and binary expressions)
- rust-lang/rust#150561 (Finish transition from `semitransparent` to `semiopaque` for `rustc_macro_transparency`)
- rust-lang/rust#150574 (Clarify `MoveData::init_loc_map`.)
- rust-lang/rust#150762 (Use functions more in rustdoc GUI tests)
- rust-lang/rust#150808 (rename the `derive_{eq, clone_copy}` features to `*_internals`)
- rust-lang/rust#150816 (Fix trait method anchor disappearing before user can click on it)
- rust-lang/rust#150821 (tests/ui/borrowck/issue-92157.rs: Remove (bug not fixed))
- rust-lang/rust#150829 (make attrs actually use `Target::GenericParam`)
- rust-lang/rust#150834 (Add tracking issue for `feature(multiple_supertrait_upcastable)`)
- rust-lang/rust#150864 (The aarch64-unknown-none target requires NEON, so the docs were wrong.)
r? @ghost
Add tracking issue for `feature(multiple_supertrait_upcastable)`
Move feature(multiple_supertrait_upcastable) to the actual feature gates section (from the internal feature gates section) and give it a tracking issue.
Tracking issue: rust-lang/rust#150833
Fixes https://github.com/rust-lang/rust/issues/150773
This feature is for the `multiple_supertrait_upcastable` lint, which was added as `unstable` without a tracking issue, but was placed in the internal feature gates section. This PR moves its listing to the actual feature gates section and gives it a tracking issue.
If the lint is intended to stay internal-only, then this can be changed to instead mark it as `internal` (and maybe close the tracking issue).
make attrs actually use `Target::GenericParam`
currently attributes lower `GenericParam` -> `Target::Param` this PR fixes this, so that `GenericParam` is lowered to `Target::GenericParam`
r? @JonathanBrouwer
tests/ui/borrowck/issue-92157.rs: Remove (bug not fixed)
The bug the test tests for is masked by the wrong `#[lang = "start"]` signature. If the signature is corrected, the test builds. But that is not because the bug is fixed, but because the test has been changed too much from the original reproducer. The original reproducer still ICE:s. See https://github.com/rust-lang/rust/issues/92157#issuecomment-3722060317.
But that's fine since in the latest compiler says:
> note: using internal features is not supported and expected to cause internal compiler errors when used incorrectly
So let's remove the test and close the issue as "won't fix". See https://github.com/rust-lang/rust/issues/92157#issuecomment-3725036997.
r? @JohnTitor since you added the test in https://github.com/rust-lang/rust/pull/106878
Fix trait method anchor disappearing before user can click on it
A good example of this bug is going to https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir_analysis/collect/struct.ItemCtxt.html#impl-HirTyLowerer%3C'tcx%3E-for-ItemCtxt%3C'tcx%3E, and then try to click on the `§` anchor of the `tcx` method.
The solution to this bug is to simply "glue" the anchor to the method, so when the mouse cursor moves to it, there is no gap between the two, preventing the anchor to disappear (hopefully this explanation doesn't make sense only to me ^^').
First commit fixes the bug by expanding the anchor size.
Second commit is a small clean-up of the GUI test.
Third commit actually adds the GUI regression test.
cc @BoxyUwU
r? @camelid
Use functions more in rustdoc GUI tests
Now that conditions are supported in `browser-ui-test`, we can start simplify some parts of the tests. This is a first cleanup, but I guess a lot more could be simplified. For follow-ups I guess. :)
I made some improvements in backtrace display in `browser-ui-test`, hence the version update once more.
r? @lolbinarycat
Finish transition from `semitransparent` to `semiopaque` for `rustc_macro_transparency`
Since it's a bit annoying to have different names for the same thing.
My understanding is that this is just internal stuff that is not part of any public API even tough rust-analyzer knows about it.
Continuation of
- https://github.com/rust-lang/rust/pull/139084.
Discovered while investigating
- https://github.com/rust-lang/rust/issues/150514
fix `Expr::can_have_side_effects` for `[x; N]` style array literal and binary expressions
AFAIK `[0; 3]` is basically a syntax sugar for `[0, 0, 0]` so it should return whether the repeat's element can have side effects, like what it does on arrays.
And it seems that the rule for unary operators and indexings can be applied to binary operators as well.
Stop emitting UbChecks on every Vec→Slice
Spotted this in rust-lang/rust#148766's test changes. It doesn't seem like this ubcheck would catch anything useful; let's see if skipping it helps perf. (After all, this is inside *every* `[]` on a vec, among other things.)
Deprecated doc intra link
fixes https://github.com/rust-lang/rust/issues/98342
r? @GuillaumeGomez
Renders intra-doc links in the note text of the `#[deprecated]` attribute. It is quite natural to suggest some other function to use there. So e.g.
```rust
#[deprecated(since = "0.0.0", note = "use [`std::mem::size_of`] instead")]
```
renders as
<img width="431" height="74" alt="Screenshot from 2026-01-06 12-08-21" src="https://github.com/user-attachments/assets/8f608f08-13ee-4bbf-a631-6008058a51e2" />
Thread `--jobs` from `bootstrap` -> `compiletest` -> `run-make-support`
Context is https://github.com/rust-lang/rust/pull/150524#issuecomment-3712701586, where we would like to thread the `--jobs` config from bootstrap explicitly through to run-make tests without relying on an "external env var" that bypasses the build/test infra.
Note that this PR currently intentionally couples the jobs configured for *builds*, versus for `TestMode::RunMake` tests. We can further specialize some kind of `run-make-jobs` bootstrap config *if actually needed*; I will keep this configuration naive for now.
r? @Kobzol
Ensure that static initializers are acyclic for NVPTX
NVPTX does not support cycles in static initializers (see rust-lang/rust#146787). LLVM produces an error when attempting to generate code for such constructs, like self-referential structs.
To avoid LLVM UB, we emit a post-monomorphization error on the Rust side before reaching codegen.
This is achieved by analyzing a subgraph of the "mono item graph" that only contains statics.
1. Calculate the strongly connected components (SCCs) of the graph.
2. Check for cycles (more than one node in an SCC or one node that references itself).
Convert static lifetime to an nll var
Fixesrust-lang/rust#150648
I don't think this matters for any non 'static lifetimes as defining the struct as `Wrap<'a>` would mean the lifetime argument gets replaced with an nll var before MIR type checking meaning the struct tail is `dyn Trait + '?x`
r? types
naked functions: emit `.private_extern` on macos
fixes https://github.com/rust-lang/rust/issues/148307
Emit `.private_extern` on macos when the naked function uses `Linkage::Internal`. Failing to do so can cause issues with LTO.
The documentation on this directive is kind of sparse, but I believe this is at least not incorrect, and does fix the issue.
r? @Amanieu
cc @bjorn3
It was added in ddee45e1d7 when SIGPIPE was controlled with an
attribute on `fn main()` which meant it could also be combined with
`#[rustc_main]`:
#[unix_sigpipe = "sig_dfl"]
#[rustc_main]
fn rustc_main() {
It stopped being needed cde0cde151 when `#[unix_sigpipe = "..."]` was
replaced by `-Zon-broken-pipe=...`. And it will not be needed when
`-Zon-broken-pipe=...` is replaced by an Externally Implementable Item.
Let's remove this test.
yukang