Give all bytes of TypeId provenance #143736

oli-obk · 2025-07-10T15:03:23Z

This makes all bytes of TypeId uninspectable at compile-time.

For context see #77125 (comment)

r? @RalfJung

rustbot · 2025-07-10T15:03:29Z

Some changes occurred to the CTFE machinery

cc @RalfJung, @oli-obk, @lcnr

Some changes occurred to the CTFE / Miri interpreter

cc @rust-lang/miri

RalfJung

LGTM, r=me with comment nits resolved. :)

RalfJung · 2025-07-11T15:13:15Z

compiler/rustc_const_eval/src/interpret/intrinsics.rs

+            let offset = self.read_scalar(&elem)?.to_target_usize(&tcx)?;
+            let ptr = Pointer::new(alloc_id.into(), Size::from_bytes(offset));


Suggested change

let offset = self.read_scalar(&elem)?.to_target_usize(&tcx)?;

let ptr = Pointer::new(alloc_id.into(), Size::from_bytes(offset));

// Decorate this part of the hash with provenance; leave the integer part unchanged.

let hash_fragment = self.read_scalar(&elem)?.to_target_usize(&tcx)?;

let ptr = Pointer::new(alloc_id.into(), Size::from_bytes(hash_fragment));

RalfJung · 2025-07-11T15:15:30Z

tests/ui/consts/const_transmute_type_id5.rs

+    let mut b = TypeId::of::<()>();
+    unsafe {
+        let ptr = &mut b as *mut TypeId as *mut *const ();
+        let val = std::ptr::read(ptr);


Suggested change

let val = std::ptr::read(ptr);

// Copy the ptr at index 0 to index 1.

let val = std::ptr::read(ptr);

oli-obk · 2025-07-14T08:34:01Z

@bors r=RalfJung

bors · 2025-07-14T08:34:04Z

📌 Commit eef08a3 has been approved by RalfJung

It is now in the queue for this repository.

oli-obk · 2025-07-15T07:44:46Z

@bors rollup

Rollup of 13 pull requests Successful merges: - #142301 (tests: Fix duplicated-path-in-error fail with musl) - #143630 (Drop `./x suggest`) - #143736 (Give all bytes of TypeId provenance) - #143752 (Don't panic if WASI_SDK_PATH not set when detecting compiler) - #143837 (Adjust `run_make_support::symbols` helpers) - #143878 (Port `#[pointee]` to the new attribute parsing infrastructure) - #143905 (Recover and suggest to use `;` to construct array type) - #143907 (core: make `str::split_at_unchecked()` inline) - #143910 (Add experimental `backtrace-trace-only` std feature) - #143927 (Preserve constness in trait objects up to hir ty lowering) - #143935 (rustc_type_ir/walk: move docstring to `TypeWalker` itself) - #143938 (Update books) - #143941 (update `cfg_select!` documentation) Failed merges: - #143926 (Remove deprecated fields in bootstrap) r? `@ghost` `@rustbot` modify labels: rollup

Rollup merge of #143736 - oli-obk:uninspectable-type-id, r=RalfJung Give all bytes of TypeId provenance This makes all bytes of TypeId uninspectable at compile-time. For context see #77125 (comment) r? ``@RalfJung``

Rollup of 13 pull requests Successful merges: - rust-lang/rust#142301 (tests: Fix duplicated-path-in-error fail with musl) - rust-lang/rust#143630 (Drop `./x suggest`) - rust-lang/rust#143736 (Give all bytes of TypeId provenance) - rust-lang/rust#143752 (Don't panic if WASI_SDK_PATH not set when detecting compiler) - rust-lang/rust#143837 (Adjust `run_make_support::symbols` helpers) - rust-lang/rust#143878 (Port `#[pointee]` to the new attribute parsing infrastructure) - rust-lang/rust#143905 (Recover and suggest to use `;` to construct array type) - rust-lang/rust#143907 (core: make `str::split_at_unchecked()` inline) - rust-lang/rust#143910 (Add experimental `backtrace-trace-only` std feature) - rust-lang/rust#143927 (Preserve constness in trait objects up to hir ty lowering) - rust-lang/rust#143935 (rustc_type_ir/walk: move docstring to `TypeWalker` itself) - rust-lang/rust#143938 (Update books) - rust-lang/rust#143941 (update `cfg_select!` documentation) Failed merges: - rust-lang/rust#143926 (Remove deprecated fields in bootstrap) r? `@ghost` `@rustbot` modify labels: rollup

…alfJung Give all bytes of TypeId provenance This makes all bytes of TypeId uninspectable at compile-time. For context see rust-lang#77125 (comment) r? ``@RalfJung``

…eltardieu Rollup of 13 pull requests Successful merges: - rust-lang#142301 (tests: Fix duplicated-path-in-error fail with musl) - rust-lang#143630 (Drop `./x suggest`) - rust-lang#143736 (Give all bytes of TypeId provenance) - rust-lang#143752 (Don't panic if WASI_SDK_PATH not set when detecting compiler) - rust-lang#143837 (Adjust `run_make_support::symbols` helpers) - rust-lang#143878 (Port `#[pointee]` to the new attribute parsing infrastructure) - rust-lang#143905 (Recover and suggest to use `;` to construct array type) - rust-lang#143907 (core: make `str::split_at_unchecked()` inline) - rust-lang#143910 (Add experimental `backtrace-trace-only` std feature) - rust-lang#143927 (Preserve constness in trait objects up to hir ty lowering) - rust-lang#143935 (rustc_type_ir/walk: move docstring to `TypeWalker` itself) - rust-lang#143938 (Update books) - rust-lang#143941 (update `cfg_select!` documentation) Failed merges: - rust-lang#143926 (Remove deprecated fields in bootstrap) r? `@ghost` `@rustbot` modify labels: rollup

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

…=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 Jul 10, 2025

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Jul 10, 2025

RalfJung reviewed Jul 11, 2025

View reviewed changes

oli-obk force-pushed the uninspectable-type-id branch from 2f16de4 to aa4675c Compare July 14, 2025 08:27

Give all bytes of TypeId provenance

eef08a3

oli-obk force-pushed the uninspectable-type-id branch from aa4675c to eef08a3 Compare July 14, 2025 08:33

bors 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-review Status: Awaiting review from the assignee but also interested parties. labels Jul 14, 2025

samueltardieu mentioned this pull request Jul 15, 2025

Rollup of 13 pull requests #143958

Merged

bors merged commit e66f26f into rust-lang:master Jul 15, 2025
11 checks passed

rustbot added this to the 1.90.0 milestone Jul 15, 2025

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

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Give all bytes of TypeId provenance #143736

Give all bytes of TypeId provenance #143736

Uh oh!

oli-obk commented Jul 10, 2025

Uh oh!

rustbot commented Jul 10, 2025

Uh oh!

RalfJung left a comment

Uh oh!

RalfJung Jul 11, 2025

Uh oh!

RalfJung Jul 11, 2025

Uh oh!

oli-obk commented Jul 14, 2025

Uh oh!

bors commented Jul 14, 2025

Uh oh!

oli-obk commented Jul 15, 2025

Uh oh!

Uh oh!

Uh oh!

		let offset = self.read_scalar(&elem)?.to_target_usize(&tcx)?;
		let ptr = Pointer::new(alloc_id.into(), Size::from_bytes(offset));

-            let offset = self.read_scalar(&elem)?.to_target_usize(&tcx)?;
-            let ptr = Pointer::new(alloc_id.into(), Size::from_bytes(offset));
+            // Decorate this part of the hash with provenance; leave the integer part unchanged.
+            let hash_fragment = self.read_scalar(&elem)?.to_target_usize(&tcx)?;
+            let ptr = Pointer::new(alloc_id.into(), Size::from_bytes(hash_fragment));

	let val = std::ptr::read(ptr);
	// Copy the ptr at index 0 to index 1.
	let val = std::ptr::read(ptr);

Give all bytes of TypeId provenance #143736

Give all bytes of TypeId provenance #143736

Uh oh!

Conversation

oli-obk commented Jul 10, 2025

Uh oh!

rustbot commented Jul 10, 2025

Uh oh!

RalfJung left a comment

Choose a reason for hiding this comment

Uh oh!

RalfJung Jul 11, 2025

Choose a reason for hiding this comment

Uh oh!

RalfJung Jul 11, 2025

Choose a reason for hiding this comment

Uh oh!

oli-obk commented Jul 14, 2025

Uh oh!

bors commented Jul 14, 2025

Uh oh!

oli-obk commented Jul 15, 2025

Uh oh!

Uh oh!

Uh oh!