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
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

RalfJung · 2025-09-23T09:09:11Z

compiler/rustc_const_eval/src/const_eval/machine.rs

+                let op = ecx.project_field(&args[0], FieldIdx::ZERO)?;
+                let op = ecx.project_index(&op, 0)?;
+                let id = ecx.read_scalar(&op)?.to_pointer(ecx)?;
+                let (ty, _offset) = ecx.get_ptr_type_id(id)?;


Can you use read_type_id instead?

Ah yea, this code predates that

compiler/rustc_const_eval/src/const_eval/type_info.rs

RalfJung · 2025-09-23T09:13:29Z

library/core/src/mem/type_info.rs

+/// Compute the type information of a concrete type.
+/// It can only be called at compile time, the backends do
+/// not implement it.
+#[rustc_intrinsic]


Typically we put all intrinsics into the intrinsics module. It's nice to have all these operations in one place since they are language primitives and thus quite different from the rest of the standard library.

Yea, for the single intrinsic scheme I agree, but it does get a bit boilerplaty to keep intrinsics separate from their one single caller if we have a lot of those

Happy to move them if my sentiment is not shared

OTOH it gets tricky to figure out what the language surface provided by the compiler is if it's spread all across libcore...

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.)

laundmo · 2025-09-23T10:23:01Z

library/core/src/mem/type_info.rs

+    /// Tuples.
+    Tuple(Tuple),
+    /// Primitives
+    Leaf,


I assume, at this early stage, Leaf is mostly a placeholder and will be renamed to something more fitting like Primitive, if not wholly replaced by variants for (kinds of) primitives?

I apologize if, in my ignorance, i'm missing something or jumping way too far ahead

Yea, you're absolutely spot on. I'll add docs for this

theemathas · 2025-09-23T10:36:51Z

library/core/src/mem/type_info.rs

+    #[unstable(feature = "type_info", issue = "146922")]
+    #[rustc_const_unstable(feature = "type_info", issue = "146922")]
+    pub const fn of<T: 'static>() -> Self {
+        TypeId::of::<T>().info()


Suggested change

TypeId::of::<T>().info()

const { TypeId::of::<T>().info() }

This makes it so that the function is callable at run time.

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.

RalfJung · 2025-09-24T11:45:50Z

compiler/rustc_const_eval/src/const_eval/type_info.rs

+        let mut ptr = self.mplace_to_ref(&fields_place)?;
+        ptr.layout = self.layout_of(Ty::new_imm_ref(
+            self.tcx.tcx,
+            self.tcx.lifetimes.re_static,
+            fields_layout.ty,
+        ))?;
+
+        let slice_type = Ty::new_imm_ref(
+            self.tcx.tcx,
+            self.tcx.lifetimes.re_static,
+            Ty::new_slice(self.tcx.tcx, field_type),
+        );
+        let slice_type = self.layout_of(slice_type)?;
+        self.unsize_into(&ptr.into(), slice_type, &fields_slice_place)?;


All this here does is construct the wide pointer for the slice, right?

Immediate::new_slice and ImmTy::from_immediate should be an easier to do that.

ah oops, good call

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

onkoe · 2025-09-24T17:10:09Z

compiler/rustc_const_eval/src/const_eval/type_info.rs

+                        ty::Tuple(fields) => {
+                            let (variant, variant_place) = downcast(sym::Tuple)?;
+                            // `Tuple` struct
+                            let tuple_place = self.project_field(&variant_place, FieldIdx::ZERO)?;
+                            assert_eq!(
+                                1,
+                                tuple_place
+                                    .layout()
+                                    .ty
+                                    .ty_adt_def()
+                                    .unwrap()
+                                    .non_enum_variant()
+                                    .fields
+                                    .len()
+                            );
+                            self.write_tuple_fields(tuple_place, fields, ty)?;
+                            variant
+                        }
+                        ty::Uint(_) | ty::Int(_) | ty::Float(_) | ty::Char | ty::Bool => {
+                            downcast(sym::Leaf)?.0
+                        }
+                        ty::Adt(_, _)
+                        | ty::Foreign(_)
+                        | ty::Str
+                        | ty::Array(_, _)
+                        | ty::Pat(_, _)
+                        | ty::Slice(_)
+                        | ty::RawPtr(..)
+                        | ty::Ref(..)
+                        | ty::FnDef(..)
+                        | ty::FnPtr(..)
+                        | ty::UnsafeBinder(..)


Adding a few comments in this function makes it much easier to edit, imv. Took me a sec to orient myself in here lol

(ignore if you want; mvp)

Suggested change

ty::Tuple(fields) => {

let (variant, variant_place) = downcast(sym::Tuple)?;

// `Tuple` struct

let tuple_place = self.project_field(&variant_place, FieldIdx::ZERO)?;

assert_eq!(

1,

tuple_place

.layout()

.ty

.ty_adt_def()

.unwrap()

.non_enum_variant()

.fields

.len()

);

self.write_tuple_fields(tuple_place, fields, ty)?;

variant

}

ty::Uint(_) | ty::Int(_) | ty::Float(_) | ty::Char | ty::Bool => {

downcast(sym::Leaf)?.0

}

ty::Adt(_, _)

| ty::Foreign(_)

| ty::Str

| ty::Array(_, _)

| ty::Pat(_, _)

| ty::Slice(_)

| ty::RawPtr(..)

| ty::Ref(..)

| ty::FnDef(..)

| ty::FnPtr(..)

| ty::UnsafeBinder(..)

ty::Tuple(fields) => {

let (variant, variant_place) = downcast(sym::Tuple)?;

// create the inner `core::mem::type_info::Tuple` struct

let tuple_place = self.project_field(&variant_place, FieldIdx::ZERO)?;

assert_eq!(

1,

tuple_place

.layout()

.ty

.ty_adt_def()

.unwrap()

.non_enum_variant()

.fields

.len()

);

self.write_tuple_fields(tuple_place, fields, ty)?;

variant

}

// write primitives directly (not much info to get)

ty::Uint(_) | ty::Int(_) | ty::Float(_) | ty::Char | ty::Bool => {

downcast(sym::Leaf)?.0

}

// other types are currently unimplemented.

//

// they'll result in `TypeKind::Unimplemented`

ty::Adt(_, _)

| ty::Foreign(_)

| ty::Str

| ty::Array(_, _)

| ty::Pat(_, _)

| ty::Slice(_)

| ty::RawPtr(..)

| ty::Ref(..)

| ty::FnDef(..)

| ty::FnPtr(..)

| ty::UnsafeBinder(..)

onkoe · 2025-09-24T17:11:51Z

compiler/rustc_const_eval/src/const_eval/type_info.rs

+    pub(crate) fn write_type_info(
+        &mut self,
+        ty: Ty<'tcx>,
+        dest: &impl Writeable<'tcx, CtfeProvenance>,
+    ) -> InterpResult<'tcx> {
+        let ty_struct = self.tcx.require_lang_item(LangItem::Type, self.tcx.span);
+        let ty_struct = self.tcx.type_of(ty_struct).instantiate_identity();
+        assert_eq!(ty_struct, dest.layout().ty);
+        let ty_struct = ty_struct.ty_adt_def().unwrap().non_enum_variant();
+        for (idx, field) in ty_struct.fields.iter_enumerated() {
+            let field_dest = self.project_field(dest, idx)?;
+            let downcast = |name: Symbol| {


a couple comments to help direct contributors (ignore if you want; MVP)

Suggested change

pub(crate) fn write_type_info(

&mut self,

ty: Ty<'tcx>,

dest: &impl Writeable<'tcx, CtfeProvenance>,

) -> InterpResult<'tcx> {

let ty_struct = self.tcx.require_lang_item(LangItem::Type, self.tcx.span);

let ty_struct = self.tcx.type_of(ty_struct).instantiate_identity();

assert_eq!(ty_struct, dest.layout().ty);

let ty_struct = ty_struct.ty_adt_def().unwrap().non_enum_variant();

for (idx, field) in ty_struct.fields.iter_enumerated() {

let field_dest = self.project_field(dest, idx)?;

let downcast = |name: Symbol| {

/// Creates a `core::mem::type_info::TypeInfo` for a given type, `ty`.

pub(crate) fn write_type_info(

&mut self,

ty: Ty<'tcx>,

dest: &impl Writeable<'tcx, CtfeProvenance>,

) -> InterpResult<'tcx> {

let ty_struct = self.tcx.require_lang_item(LangItem::Type, self.tcx.span);

let ty_struct = self.tcx.type_of(ty_struct).instantiate_identity();

assert_eq!(ty_struct, dest.layout().ty);

let ty_struct = ty_struct.ty_adt_def().unwrap().non_enum_variant();

// fill each field of `TypeInfo`

for (idx, field) in ty_struct.fields.iter_enumerated() {

let field_dest = self.project_field(dest, idx)?;

let downcast = |name: Symbol| {

bors · 2025-09-28T21:02:36Z

☔ The latest upstream changes (presumably #147128) made this pull request unmergeable. Please resolve the merge conflicts.

james7132 · 2025-09-30T02:53:45Z

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

TypeId::info would not be callable/panic at runtime, but would a const Type value produced from const evaluation be valid at runtime? or would users need to extract that information into a runtime-friendly mirror?

rustbot · 2025-09-30T16:08:56Z

This PR was rebased onto a different master commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

oli-obk · 2025-09-30T16:11:41Z

Id::info would not be callable/panic at runtime, but would a const Type value produced from const evaluation be valid at runtime?

yea, just like any other value until we get runtime-sized types. You just can't look through further TypeIds that are contained within them

rustbot · 2025-10-01T08:19:15Z

Some changes occurred in src/tools/clippy

cc @rust-lang/clippy

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/type_info.rs Show resolved Hide resolved

RalfJung reviewed Sep 23, 2025

View reviewed changes

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

theemathas reviewed Sep 23, 2025

View reviewed changes

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

onkoe reviewed Sep 24, 2025

View reviewed changes

oli-obk force-pushed the comptime-reflect branch from a77bbe2 to 4d1d728 Compare September 30, 2025 16:08

oli-obk force-pushed the comptime-reflect branch from 4d1d728 to c1926e6 Compare September 30, 2025 16:29

This comment has been minimized.

Sign in to view

oli-obk added 2 commits October 1, 2025 08:19

Compile-Time Reflection MVP: tuples

bad530b

Add size information

5155c5f

oli-obk force-pushed the comptime-reflect branch from c1926e6 to 5155c5f Compare October 1, 2025 08:19

rustbot added the T-clippy Relevant to the Clippy team. label Oct 1, 2025


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

Reflection MVP #146923

Are you sure you want to change the base?

Reflection MVP #146923

Uh oh!

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.

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

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!

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!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

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!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

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!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

bors commented Sep 28, 2025

Uh oh!

james7132 commented Sep 30, 2025

Uh oh!

rustbot commented Sep 30, 2025

Uh oh!

oli-obk commented Sep 30, 2025

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