Make TypeId const comparable #142789

oli-obk · 2025-06-20T16:13:56Z

This should unblock stabilizing const TypeId::of and allow us to progress into any possible future we want to take TypeId to.

To achieve that TypeId now contains 16 / size_of<usize>() pointers which each are actually just size_of<usize>() bytes of the stable hash. At compile-time the first of these pointers cannot be dereferenced or otherwise inspected (at present doing so might ICE the compiler). Preventing inspection of this data allows us to refactor TypeId to any other scheme in the future without breaking anyone who was tempted to transmute TypeId to obtain the hash at compile-time.

cc @eddyb for their previous work on #95845 (which we still can do in the future if we want to get rid of the hash as the final thing that declares two TypeIds as equal).

Tracking Issue for const fn type_id #77125

r? @RalfJung

rustbot · 2025-06-20T16:14:02Z

Some changes occurred to the intrinsics. Make sure the CTFE / Miri interpreter
gets adapted for the changes, if necessary.

cc @rust-lang/miri, @RalfJung, @oli-obk, @lcnr

Some changes occurred in compiler/rustc_codegen_cranelift

cc @bjorn3

Some changes occurred to the CTFE / Miri interpreter

cc @rust-lang/miri, @RalfJung, @oli-obk, @lcnr

Some changes occurred to the CTFE / Miri interpreter

cc @rust-lang/miri

Some changes occurred to the CTFE machinery

cc @RalfJung, @oli-obk, @lcnr

Some changes occurred in compiler/rustc_codegen_gcc

cc @antoyo, @GuillaumeGomez

library/core/src/intrinsics/mod.rs

library/core/src/any.rs

RalfJung · 2025-06-21T10:37:29Z

It will be a while until I have the capacity to review a PR of this scale.

Meanwhile, could you say a bit more about the architecture of the change? It seems you want for the "new kind of allocation" approach, but it's not clear from the PR description how exactly that shows up in TypeId.

Also, I am definitely not comfortable landing this by myself, I can only review the const-eval parts. Changing the representation of TypeId has ramifications well beyond that that I do not feel qualified to evaluate -- I think an MCP would be justified.

rustbot · 2025-06-21T11:17:11Z

Some changes occurred in compiler/rustc_codegen_ssa

cc @WaffleLapkin

oli-obk · 2025-06-21T11:18:41Z

Well, I got private feedback yesterday that instead of encoding a 16 byte value as an 8 byte pointer to the 16 byte value and an 8 byte hash, I should just do the thing where we split up type id internally into pointer sized chunks and codegen will make a hash out of it again.

TLDR: no changes to runtime type id anymore in the latest revision of this PR. Only compile-time type id is now a bit funny

oli-obk · 2025-06-21T11:22:11Z

It will be a while until I have the capacity to review a PR of this scale.

I'm splitting unrelated parts out, so the high level feedback is already useful and I'll look for libs and codegen ppl to review the appropriate parts

compiler/rustc_codegen_gcc/src/common.rs

compiler/rustc_codegen_cranelift/src/constant.rs

Make `PartialEq` a `const_trait` r? `@fee1-dead` or `@compiler-errors` something generally useful but also required for rust-lang#142789

Make `PartialEq` a `const_trait` r? ``@fee1-dead`` or ``@compiler-errors`` something generally useful but also required for rust-lang#142789

Rollup merge of #142822 - oli-obk:const-partial-eq, r=fee1-dead Make `PartialEq` a `const_trait` r? ``@fee1-dead`` or ``@compiler-errors`` something generally useful but also required for #142789

bors · 2025-06-23T16:57:20Z

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

compiler/rustc_codegen_cranelift/src/constant.rs

rust-log-analyzer · 2025-07-09T15:52:22Z

A job failed! Check out the build log: (web) (plain enhanced) (plain)

Click to see the possible cause of the failure (guessed by this bot)

oli-obk · 2025-07-09T15:52:28Z

uh

oli-obk · 2025-07-09T15:54:21Z

@bors treeclosed

Kobzol · 2025-07-09T16:04:23Z

@bors treeclosed=100 Wrong commit appeared in master.

RalfJung · 2025-07-09T16:17:40Z

I accidentally triggered a try job on both bors' above... and I guess the one on old bors was still running when the PR got r+'d, and then we got the known issue that bors mixes up try builds and approvals and gets really confused.

Given that new bors has been doing pretty well with try jobs, can we just forbid them on old bors? Or is even that redeploy too risky?^^

oli-obk · 2025-07-09T16:20:39Z

@bors treeclosed-

Kobzol · 2025-07-09T16:23:33Z

This PR is bricked and bors doesn't listen here anymore 😆 But please don't reopen yet.

oli-obk · 2025-07-09T16:23:49Z

I will create a new PR in general

oli-obk · 2025-07-09T16:23:55Z

not touching this one anymore :D

jdonszelmann · 2025-07-09T16:31:43Z

forced pushed to master from the mobile command centre :3

@pietroalbini, @scrabsha

Add opaque TypeId handles for CTFE Reopen of #142789 (comment) after some bors insta-merge chaos r? `@RalfJung`

Add opaque TypeId handles for CTFE Reopen of rust-lang#142789 (comment) after some bors insta-merge chaos r? `@RalfJung`

Add opaque TypeId handles for CTFE Reopen of rust-lang/rust#142789 (comment) after some bors insta-merge chaos r? `@RalfJung`

fix handling of base address for TypeId allocations This fixes the problems discovered by `@theemathas` in rust-lang#142789: - const-eval would sometimes consider TypeId pointers to be null - the type ID is different in Miri than in regular executions Both boil down to the same issue: the TypeId "allocation" has a guaranteed 0 base address, but const-eval assumes it was non-zero (like normal allocations) and Miri randomized it (like normal allocations). r? `@oli-obk`

fix handling of base address for TypeId allocations This fixes the problems discovered by ``@theemathas`` in rust-lang#142789: - const-eval would sometimes consider TypeId pointers to be null - the type ID is different in Miri than in regular executions Both boil down to the same issue: the TypeId "allocation" has a guaranteed 0 base address, but const-eval assumes it was non-zero (like normal allocations) and Miri randomized it (like normal allocations). r? ``@oli-obk``

fix handling of base address for TypeId allocations This fixes the problems discovered by ```@theemathas``` in rust-lang#142789: - const-eval would sometimes consider TypeId pointers to be null - the type ID is different in Miri than in regular executions Both boil down to the same issue: the TypeId "allocation" has a guaranteed 0 base address, but const-eval assumes it was non-zero (like normal allocations) and Miri randomized it (like normal allocations). r? ```@oli-obk```

fix handling of base address for TypeId allocations This fixes the problems discovered by ````@theemathas```` in rust-lang#142789: - const-eval would sometimes consider TypeId pointers to be null - the type ID is different in Miri than in regular executions Both boil down to the same issue: the TypeId "allocation" has a guaranteed 0 base address, but const-eval assumes it was non-zero (like normal allocations) and Miri randomized it (like normal allocations). r? ````@oli-obk````

Rollup merge of #144187 - RalfJung:type-id-base-addr, r=oli-obk fix handling of base address for TypeId allocations This fixes the problems discovered by ````@theemathas```` in #142789: - const-eval would sometimes consider TypeId pointers to be null - the type ID is different in Miri than in regular executions Both boil down to the same issue: the TypeId "allocation" has a guaranteed 0 base address, but const-eval assumes it was non-zero (like normal allocations) and Miri randomized it (like normal allocations). r? ````@oli-obk````

fix handling of base address for TypeId allocations This fixes the problems discovered by ````@theemathas```` in rust-lang/rust#142789: - const-eval would sometimes consider TypeId pointers to be null - the type ID is different in Miri than in regular executions Both boil down to the same issue: the TypeId "allocation" has a guaranteed 0 base address, but const-eval assumes it was non-zero (like normal allocations) and Miri randomized it (like normal allocations). r? ````@oli-obk````

…=lcnr Stabilize const TypeId::of fixes rust-lang#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 * rust-lang#142789 * rust-lang#143696 * rust-lang#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? rust-lang#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

…=lcnr Stabilize const TypeId::of fixes rust-lang#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 * rust-lang#142789 * rust-lang#143696 * rust-lang#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? rust-lang#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

…=lcnr Stabilize const TypeId::of fixes rust-lang#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 * rust-lang#142789 * rust-lang#143696 * rust-lang#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? rust-lang#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 assigned RalfJung Jun 20, 2025

This comment has been minimized.

Sign in to view

Dante-Broggi reviewed Jun 21, 2025

View reviewed changes

library/core/src/intrinsics/mod.rs Outdated Show resolved Hide resolved

Noratrieb reviewed Jun 21, 2025

View reviewed changes

library/core/src/any.rs Outdated Show resolved Hide resolved

oli-obk force-pushed the constable-type-id branch from 3cddd21 to 1fd7b66 Compare June 21, 2025 10:20

This comment has been minimized.

Sign in to view

oli-obk mentioned this pull request Jun 21, 2025

Make PartialEq a const_trait #142822

Merged

This comment has been minimized.

Sign in to view

antoyo reviewed Jun 21, 2025

View reviewed changes

compiler/rustc_codegen_gcc/src/common.rs Outdated Show resolved Hide resolved

bjorn3 reviewed Jun 21, 2025

View reviewed changes

compiler/rustc_codegen_cranelift/src/constant.rs Outdated Show resolved Hide resolved

oli-obk force-pushed the constable-type-id branch 2 times, most recently from b8a7a10 to 1c47a64 Compare June 24, 2025 09:25

bjorn3 reviewed Jun 24, 2025

View reviewed changes

compiler/rustc_codegen_cranelift/src/constant.rs Outdated Show resolved Hide resolved

This comment has been minimized.

Sign in to view

oli-obk force-pushed the constable-type-id branch from 1c47a64 to bcb4aa2 Compare June 24, 2025 13:02

This comment has been minimized.

Sign in to view

bjorn3 reviewed Jun 24, 2025

View reviewed changes

compiler/rustc_codegen_cranelift/src/constant.rs Outdated Show resolved Hide resolved

bors merged commit 048b879 into rust-lang:master Jul 9, 2025
13 checks passed

rustbot added this to the 1.90.0 milestone Jul 9, 2025

oli-obk deleted the constable-type-id branch July 9, 2025 15:54

oli-obk mentioned this pull request Jul 9, 2025

Add opaque TypeId handles for CTFE #143696

Merged

bors added a commit that referenced this pull request Jul 10, 2025

Auto merge of #143696 - oli-obk:constable-type-id2, r=RalfJung

cf3fb76

Add opaque TypeId handles for CTFE Reopen of #142789 (comment) after some bors insta-merge chaos r? `@RalfJung`

oli-obk mentioned this pull request Jul 10, 2025

Tracking Issue for const fn type_id #77125

Open

4 tasks

oli-obk mentioned this pull request Jul 18, 2025

Stabilize const TypeId::of #144133

Open

Aeledfyr mentioned this pull request Jul 18, 2025

std::fmt::Debug for TypeId triggers false positive UB warning rust-lang/miri#4477

Closed

RalfJung mentioned this pull request Jul 19, 2025

fix handling of base address for TypeId allocations #144187

Merged

Make TypeId const comparable #142789

Make TypeId const comparable #142789

Uh oh!

Conversation

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

Uh oh!

Uh oh!

rustbot commented Jun 20, 2025

Uh oh!

This comment has been minimized.

Uh oh!

Uh oh!

This comment has been minimized.

RalfJung commented Jun 21, 2025

Uh oh!

rustbot commented Jun 21, 2025

Uh oh!

oli-obk commented Jun 21, 2025

Uh oh!

oli-obk commented Jun 21, 2025

Uh oh!

This comment has been minimized.

Uh oh!

Uh oh!

bors commented Jun 23, 2025

Uh oh!

Uh oh!

This comment has been minimized.

This comment has been minimized.

Uh oh!

Uh oh!

rust-log-analyzer commented Jul 9, 2025

Uh oh!

oli-obk commented Jul 9, 2025

Uh oh!

oli-obk commented Jul 9, 2025

Uh oh!

Kobzol commented Jul 9, 2025

Uh oh!

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

Uh oh!

Uh oh!

oli-obk commented Jul 9, 2025

Uh oh!

Kobzol commented Jul 9, 2025

Uh oh!

oli-obk commented Jul 9, 2025

Uh oh!

oli-obk commented Jul 9, 2025

Uh oh!

jdonszelmann commented Jul 9, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

oli-obk commented Jun 20, 2025 •

edited

Loading

RalfJung commented Jul 9, 2025 •

edited

Loading

jdonszelmann commented Jul 9, 2025 •

edited

Loading