Reflection MVP #146923

oli-obk · 2025-09-23T08:10:45Z

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: rust-lang/rust-project-goals#406
tracking issue: #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

rustbot · 2025-09-23T08:10:49Z

Some changes occurred to the CTFE / Miri interpreter

cc @rust-lang/miri

Some changes occurred to the CTFE machinery

cc @RalfJung, @oli-obk, @lcnr

compiler/rustc_const_eval/src/const_eval/machine.rs

compiler/rustc_const_eval/src/const_eval/type_info.rs

library/core/src/mem/type_info.rs

RalfJung · 2025-09-23T09:51:31Z

library/core/src/mem/type_info.rs

+    /// It can only be called at compile time.
+    #[unstable(feature = "type_info", issue = "146922")]
+    #[rustc_const_unstable(feature = "type_info", issue = "146922")]
+    pub const fn info(self) -> Type {


This currently has zero regards for semver, right?

Yea, but it also only supports tuples, which was an explicit choice so we can handle semver related things when we support Adts

Unless you mean the fact that it allows inspecting a generic param and now knowing it's a tuple. This can look through opaque types and stuff

Oh right it also breaks parametricity (though specialization also does that).

Not super relevant right now, but I hope "discuss semver considerations" is a major item somewhere on the agenda for this feature. ;) (The tracking issue is still rather barebones at the moment.)

Maybe controversial, but could Type be limited to viewing types within the current crate, and anything outside it simply be Opaque/Foreign/etc.? Libraries that want the Type of one of their types to be part of the public API could then expose it via a public constant or function returning said constant.

library/core/src/mem/type_info.rs

theemathas · 2025-09-23T10:44:46Z

It seems like... trying to obtain a Type of a struct causes an ICE?

oli-obk · 2025-09-23T12:52:40Z

It seems like... trying to obtain a Type of a struct causes an ICE?

Oh whoops, that shouldn't happen. I'll add some more tests

library/core/src/mem/type_info.rs

juntyr · 2025-09-23T13:11:14Z

library/core/src/mem/type_info.rs

+    /// Primitives
+    Leaf,
+    /// FIXME(#146922): add all the common types
+    Unimplemented,


See https://docs.rs/const-type-layout/latest/const_type_layout/struct.TypeLayoutInfo.html for some prior work

RalfJung · 2025-09-24T06:59:11Z

This is an MVP. Please do not flood this PR with all your wildest reflection dreams. Anything that suggests to extend the scope of this PR is off-topic.

theemathas · 2025-09-24T07:27:12Z

Currently, this implementation says that, in the type (u8, dyn Send), the offset of the dyn Send field is 1. Is this correct? I believe that there will be padding bytes before the dyn Send field to make the data inside aligned.

compiler/rustc_const_eval/src/const_eval/type_info.rs

onkoe

newer contributor here. basically, I just got some nits you can ignore :)

thank you so much for working on this!!! :D

View changes since this review

onkoe · 2025-09-24T16:32:46Z

library/core/src/mem/mod.rs


+#[unstable(feature = "type_info", issue = "146922")]
+pub mod type_info;


This might be on purpose, but did you intend to use the same re-export pattern as above?

Otherwise, wouldn't this make a guarantee that everything in this module would become unstable/stable at the same time? (and prevent making changes to those internals..?)

if other MVPs tend to ignore this stuff, please ignore this comment :)

if I make the module stable, its internals would not become stable. The module may also stay unstable forever. For easier usage while entirely unstable I'm just making the module publicly available so all internals can be used and played with

compiler/rustc_const_eval/src/const_eval/type_info.rs

oli-obk · 2026-01-09T15:14:19Z

@bors r=BoxyUwU

rust-bors · 2026-01-09T15:14:23Z

📌 Commit 82028b0 has been approved by BoxyUwU

It is now in the queue for this repository.

@scottmcm

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: rust-lang/rust-project-goals#406 tracking issue: rust-lang#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

@scottmcm

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: rust-lang/rust-project-goals#406 tracking issue: rust-lang#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

matthiaskrgr · 2026-01-10T14:30:59Z

@bors p=6
since this is at the bottom now due to ordering bug rust-lang/bors#605

rust-bors · 2026-01-10T19:04:39Z

☀️ Test successful - CI
Approved by: BoxyUwU
Pushing f57eac1 to main...

github-actions · 2026-01-10T19:07:27Z

What is this?

This is an experimental post-merge analysis report that shows differences in test outcomes between the merged PR and its parent PR.

Comparing 1b9ae9e (parent) -> f57eac1 (this PR)

Test differences

Show 172 test diffs

Stage 1

[ui] tests/ui/reflection/dump.rs: [missing] -> pass (J1)
[ui] tests/ui/reflection/feature_gate.rs: [missing] -> pass (J1)
[ui] tests/ui/reflection/tuples.rs: [missing] -> pass (J1)

Stage 2

[ui] tests/ui/reflection/dump.rs: [missing] -> pass (J0)
[ui] tests/ui/reflection/feature_gate.rs: [missing] -> pass (J0)
[ui] tests/ui/reflection/tuples.rs: [missing] -> pass (J0)

Additionally, 166 doctest diffs were found. These are ignored, as they are noisy.

Job group index

Test dashboard

Run

cargo run --manifest-path src/ci/citool/Cargo.toml -- \
    test-dashboard f57eac1bf98cb5d578e3364b64365ec398c137df --output-dir test-dashboard

And then open test-dashboard/index.html in your browser to see an overview of all executed tests.

Job duration changes

dist-apple-various: 4445.5s -> 3152.6s (-29.1%)
dist-x86_64-apple: 9025.2s -> 6876.6s (-23.8%)
pr-check-1: 1668.6s -> 2041.7s (+22.4%)
i686-gnu-2: 5277.0s -> 6131.2s (+16.2%)
test-various: 6612.2s -> 7617.9s (+15.2%)
x86_64-gnu-llvm-21-1: 3912.6s -> 4478.4s (+14.5%)
x86_64-gnu-llvm-20-2: 5098.1s -> 5804.9s (+13.9%)
x86_64-gnu-llvm-20-1: 3821.5s -> 4337.6s (+13.5%)
armhf-gnu: 4942.1s -> 5585.1s (+13.0%)
aarch64-gnu-debug: 3933.2s -> 4383.9s (+11.5%)

How to interpret the job duration changes?

Job durations can vary a lot, based on the actual runner instance
that executed the job, system noise, invalidated caches, etc. The table above is provided
mostly for t-infra members, for simpler debugging of potential CI slow-downs.

rust-timer · 2026-01-10T19:47:03Z

Finished benchmarking commit (f57eac1): comparison URL.

Overall result: no relevant changes - no action needed

@rustbot label: -perf-regression

Instruction count

This benchmark run did not return any relevant results for this metric.

Max RSS (memory usage)

Results (primary -1.9%, secondary 0.7%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	1.7%	[0.5%, 2.9%]	9
Improvements ✅ (primary)	-1.9%	[-1.9%, -1.9%]	1
Improvements ✅ (secondary)	-3.6%	[-4.6%, -2.6%]	2
All ❌✅ (primary)	-1.9%	[-1.9%, -1.9%]	1

Cycles

Results (primary -2.4%, secondary -0.8%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	2.8%	[2.8%, 2.8%]	1
Improvements ✅ (primary)	-2.4%	[-3.1%, -2.0%]	4
Improvements ✅ (secondary)	-2.5%	[-2.6%, -2.5%]	2
All ❌✅ (primary)	-2.4%	[-3.1%, -2.0%]	4

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 472.721s -> 473.812s (0.23%)
Artifact size: 391.33 MiB -> 391.34 MiB (0.00%)

rustbot assigned scottmcm Sep 23, 2025

oli-obk force-pushed the comptime-reflect branch 2 times, most recently from aab0141 to 4234855 Compare September 23, 2025 08:12

This comment has been minimized.

Sign in to view

oli-obk force-pushed the comptime-reflect branch from 4234855 to 6dd9a6a Compare September 23, 2025 08:25

oli-obk assigned joshtriplett Sep 23, 2025

This comment has been minimized.

Sign in to view

oli-obk force-pushed the comptime-reflect branch from 6dd9a6a to a77bbe2 Compare September 23, 2025 08:47

RalfJung reviewed Sep 23, 2025

View reviewed changes

compiler/rustc_const_eval/src/const_eval/machine.rs Outdated Show resolved Hide resolved

RalfJung reviewed Sep 23, 2025

View reviewed changes

compiler/rustc_const_eval/src/const_eval/type_info.rs Show resolved Hide resolved

RalfJung reviewed Sep 23, 2025

View reviewed changes

library/core/src/mem/type_info.rs Outdated Show resolved Hide resolved

This comment has been minimized.

Sign in to view

RalfJung reviewed Sep 23, 2025

View reviewed changes

laundmo reviewed Sep 23, 2025

View reviewed changes

library/core/src/mem/type_info.rs Show resolved Hide resolved

theemathas reviewed Sep 23, 2025

View reviewed changes

library/core/src/mem/type_info.rs Outdated Show resolved Hide resolved

juntyr reviewed Sep 23, 2025

View reviewed changes

This comment has been minimized.

Sign in to view

RalfJung reviewed Sep 24, 2025

View reviewed changes

compiler/rustc_const_eval/src/const_eval/type_info.rs Outdated Show resolved Hide resolved

onkoe reviewed Sep 24, 2025

View reviewed changes

Add size information

82028b0

oli-obk force-pushed the comptime-reflect branch from 13e3656 to 82028b0 Compare January 9, 2026 15:13

rust-bors bot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jan 9, 2026

rust-bors bot added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Jan 9, 2026

Zalathar mentioned this pull request Jan 10, 2026

Rollup of 15 pull requests #150914

Closed

JonathanBrouwer mentioned this pull request Jan 10, 2026

Rollup of 14 pull requests #150924

Closed

This comment has been minimized.

Sign in to view

matthiaskrgr mentioned this pull request Jan 10, 2026

Rollup of 11 pull requests #150912

Merged

rust-bors bot added the merged-by-bors This PR was explicitly merged by bors. label Jan 10, 2026

rust-bors bot merged commit f57eac1 into rust-lang:main Jan 10, 2026
12 checks passed

rustbot added this to the 1.94.0 milestone Jan 10, 2026

This was referenced Jan 10, 2026

Add missing impl Fn for &mut F where F: Fn #148271

Open

support c-variadic functions in rustc_const_eval #150601

Open

include HirIds directly in the THIR, not wrapped in LintLevels #150846

Open

oli-obk deleted the comptime-reflect branch January 10, 2026 19:27

4r33x mentioned this pull request Jan 11, 2026

[Feature] Better build system 4r33x/proto-rs#232

Open

traviscross added the I-lang-radar Items that are on lang's radar and will need eventual work or consideration. label Jan 11, 2026

BD103 mentioned this pull request Jan 12, 2026

Type:of does not support types without a size #151018

Closed

SpriteOvO added the F-type_info #![feature(type_info)] label Jan 14, 2026

SpriteOvO mentioned this pull request Jan 14, 2026

Support ADT types in type info reflection #151142

Draft

5 tasks


		#[unstable(feature = "type_info", issue = "146922")]
		pub mod type_info;

Uh oh!

Reflection MVP #146923

Reflection MVP #146923

Conversation

oli-obk commented Sep 23, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rustbot commented Sep 23, 2025

Uh oh!

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

Uh oh!

Uh oh!

Uh oh!

This comment has been minimized.

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

theemathas commented Sep 23, 2025

Uh oh!

oli-obk commented Sep 23, 2025

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

This comment has been minimized.

This comment has been minimized.

RalfJung commented Sep 24, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

theemathas commented Sep 24, 2025

Uh oh!

Uh oh!

onkoe left a comment • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

oli-obk commented Jan 9, 2026

Uh oh!

rust-bors bot commented Jan 9, 2026

Uh oh!

matthiaskrgr commented Jan 10, 2026

Uh oh!

This comment has been minimized.

rust-bors bot commented Jan 10, 2026

Uh oh!

Uh oh!

github-actions bot commented Jan 10, 2026

Test differences

Stage 1

Stage 2

Job duration changes

Uh oh!

rust-timer commented Jan 10, 2026

Overall result: no relevant changes - no action needed

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

oli-obk commented Sep 23, 2025 •

edited

Loading

RalfJung commented Sep 24, 2025 •

edited

Loading

onkoe left a comment •

edited by rustbot

Loading