Stabilize const TypeId::of

[oli-obk]

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

• Make TypeId const comparable #142789
• Add opaque TypeId handles for CTFE  #143696
• Give all bytes of TypeId provenance #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 TypeIds, 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?

#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

[rustbot]

r? @lcnr

rustbot has assigned @lcnr.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[rustbot]

Some changes occurred to MIR optimizations

cc @rust-lang/wg-mir-opt

[RalfJung]

OTOH type_name is so clearly documented as being not injective that I am totally fine with stabilizing it if there's a good usecase. Every API relying on type_name comparison is so obviously unsound, I'm not worried about this happening accidentally.

But there's no reason to stabilize it together with TypeId::of.

[theemathas]

Edit: #144187 does NOT change the behavior of this code.

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.

I'm not sure what exactly you mean by this, but here's some weird code.

#![feature(const_type_id)]

use std::mem::transmute;
use std::any::TypeId;

const fn assert_same_type<T: 'static, U: 'static>() {
    unsafe {
        let id1: TypeId = TypeId::of::<T>();
        let [ptr1, _]: [*const u8; 2] = transmute(id1);
        let id2: TypeId = TypeId::of::<U>();
        let [ptr2, _]: [*const u8; 2] = transmute(id2);
        let _ = ptr1.offset_from(ptr2);
        // This also works:
        // let _ = ptr1.wrapping_add(1).offset_from(ptr2.wrapping_add(1)));
    }
}

const WORKS: () = assert_same_type::<i32, i32>();
const FAILS: () = assert_same_type::<i32, i64>();

Compile error

error[E0080]: `ptr_offset_from` called on two different pointers that are not both derived from the same allocation
   --> src/lib.rs:19:19
    |
19  | const FAILS: () = assert_same_type::<i32, i64>();
    |                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ evaluation of `FAILS` failed inside this call
    |
note: inside `assert_same_type::<i32, i64>`
   --> src/lib.rs:12:17
    |
12  |         let _ = ptr1.offset_from(ptr2);
    |                 ^^^^^^^^^^^^^^^^^^^^^^
note: inside `std::ptr::const_ptr::<impl *const u8>::offset_from`
   --> /playground/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/ptr/const_ptr.rs:671:18
    |
671 |         unsafe { intrinsics::ptr_offset_from(self, origin) }
    |                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the failure occurred here

For more information about this error, try `rustc --explain E0080`.
error: could not compile `playground` (lib) due to 1 previous error

[RalfJung]

Yes it's possible to write a function that is UB (and thus may halt evaluation) if and only if the two TypeId are different. I wouldn't call this a valid equality test...

You can't use this to do anything conditional on that result though, it just stops compilation (or does whatever else const UB may do). So not sure if it's worth trying to stop this.

[oli-obk]

LMAO I guess we should have gone with Ralf's route of not reusing AllocIds after all.

[theemathas]

Edit: As of #144187, both WORKS and FAILS now fail to compile. That is, I can no longer observe the TypeId bytes in const.

I managed to write some code that compiles or not depending on the hash value inside TypeId.

Code

(tested on the playground with 1.90.0-nightly (2025-07-17 e4662966273ed58b51f9)

#![feature(const_type_id)]

use std::mem::transmute;
use std::any::TypeId;

/*
// I used this code to make the compiler tell me what the hash is

trait Super {}
trait Sub: Super {}

const SHOW_HASH_1: () = unsafe {
    let id = TypeId::of::<i32>();
    let [first, second]: [*const (); 2] = transmute(id);
    let ptr: *const dyn Sub = transmute([second, first]);
    let _: *const dyn Super = ptr;
};

const SHOW_HASH_2: () = unsafe {
    let id = TypeId::of::<i32>();
    let ptr: *const dyn Sub = transmute(id);
    let _: *const dyn Super = ptr;
};
*/

const HASH_1: usize = 0x50bb9674fa2df013;
const HASH_2: usize = 0x56ced5e4a15bd890;

const fn assert_is_i32<T: 'static, const A: usize, const B: usize>() {
    const { unsafe {
        let id = TypeId::of::<T>();
        let [ptr1, _]: [*const u8; 2] = transmute(id);
        &*ptr1.wrapping_sub(A).cast::<()>()
    }};
    const { unsafe {
        let id = TypeId::of::<T>();
        let [_, ptr2]: [*const u8; 2] = transmute(id);
        &*ptr2.wrapping_sub(B).cast::<()>()
    }};
}

const WORKS: () = assert_is_i32::<i32, HASH_1, HASH_2>();
const FAILS: () = assert_is_i32::<i64, HASH_1, HASH_2>();

error[E0080]: constructing invalid value: encountered a null reference
  --> src/lib.rs:30:11
   |
30 |       const { unsafe {
   |  ___________^
31 | |         let id = TypeId::of::<T>();
32 | |         let [ptr1, _]: [*const u8; 2] = transmute(id);
33 | |         &*ptr1.wrapping_sub(A).cast::<()>()
34 | |     }};
   | |______^ it is undefined behavior to use this value
   |
   = note: The rules on what exactly is undefined behavior aren't clear, so this check might be overzealous. Please open an issue on the rustc repository if you believe it should not be considered undefined behavior.
   = note: the raw bytes of the constant (size: 8, align: 8) {
               ╾a27+0xaf86f48ac476294e<imm> (8 ptr bytes)╼                         │ ╾──────╼
           }

note: erroneous constant encountered
  --> src/lib.rs:30:5
   |
30 | /     const { unsafe {
31 | |         let id = TypeId::of::<T>();
32 | |         let [ptr1, _]: [*const u8; 2] = transmute(id);
33 | |         &*ptr1.wrapping_sub(A).cast::<()>()
34 | |     }};
   | |______^

For more information about this error, try `rustc --explain E0080`.
error: could not compile `playground` (lib) due to 1 previous error

[oli-obk]

I think that is the same situation as you had before. You can't make an if is::<T, u32>() {5} else { 6 } check with this, even if you know the exact hash.

[RalfJung]

Yeah, that's fundamentally the same thing as above.

[scottmcm]

I think I agree that I'm not particularly concerned by code like that. Compared to other ways that you can break compilation between versions using const, it feels very minor. For example, you can currently compile

u128::from_be_bytes([0; core::char::UNICODE_VERSION.0 as _])

which is obviously a bad idea, so I think any transmute tricks on TypeId aren't worth worrying about so long as they don't let you bust the use-the-integer-value firewall.

[theemathas]

Edit: As of #144187, both YES and NAH evaluate to false. That is, I can no longer observe the TypeId bytes in const.

In combination with const_raw_ptr_comparison, I can actually check for type equality and actually produce a bool.

Code

#![feature(const_type_id, const_raw_ptr_comparison)]

use std::any::TypeId;
use std::mem::transmute;
use std::ptr::null;

const HASH_1: usize = 0x50bb9674fa2df013;
const HASH_2: usize = 0x56ced5e4a15bd890;

const fn is_i32<T: 'static>() -> bool {
    unsafe {
        let id = TypeId::of::<T>();
        let [ptr1, ptr2]: [*const u8; 2] = transmute(id);
        matches!(ptr1.wrapping_sub(HASH_1).guaranteed_eq(null()), Some(false))
            && matches!(ptr2.wrapping_sub(HASH_2).guaranteed_eq(null()), Some(false))
    }
}

const YES: bool = is_i32::<i32>();
const NAH: bool = is_i32::<i64>();

fn main() {
    println!("{YES}");  // prints "true"
    println!("{NAH}");  // prints "false"
}

[programmerjake]

In combination with const_raw_ptr_comparison, I can actually check for type equality and actually produce a bool.

A possible solution is to make CTFE pointer comparison check the provenance and always return unknown if either or both pointers are TypeIds, regardless of if they're the same.

[oli-obk]

Raw pointer comparison in consts are unstable and will stabilize after const traits if ever. With const traits we get real comparisons and do not need to concern ourselves with preventing hacky workarounds

[theemathas]

Edit: As of #144187, is_in_const panics in consteval. That is, I can no longer observe the TypeId bytes in const, and can no longer use this method to determine whether we're running in consteval or not.

I'd like to present some more cursed code:

#![feature(const_type_id)]

use std::any::TypeId;
use std::mem::transmute;

const HASH_1: usize = 0x50bb9674fa2df013;

const fn is_in_const() -> bool {
    unsafe {
        let id = TypeId::of::<i32>();
        let [ptr1, _]: [*const u8; 2] = transmute(id);
        let ptr_zero = ptr1.wrapping_sub(HASH_1);
        !ptr_zero.is_null()
    }
}

fn main() {
    println!("{}", const { is_in_const() });  // prints "true"
    println!("{}", is_in_const());  // prints "false" normally, prints "true" in Miri
}

[Zalathar]

Still trying to track down #144995 (comment)

@bors try jobs=dist-ohos-x86_64

[rust-bors]

⌛ Trying commit 4653b7a with merge 6a17de0…

To cancel the try build, run the command @bors try cancel.

[rust-bors]

☀️ Try build successful (CI)
Build commit: 6a17de0 (6a17de04c86c6ce70c9997da5abf42cf3a0e4b98, parent: 6bcdcc73bd11568fd85f5a38b58e1eda054ad1cd)

[samueltardieu]

Still chasing the failure in #144952 (comment)

@bors try jobs=test-various

[rust-bors]

⌛ Trying commit 4653b7a with merge 285b6fd…

To cancel the try build, run the command @bors try cancel.

[rust-bors]

☀️ Try build successful (CI)
Build commit: 285b6fd (285b6fd0c43db4bf221214cbfb959a59dce7deff, parent: 61cb1e97fcf954c37d0a457a8084ed9ad8b3cb82)