Make TypeId const comparable #142789
Open
Make TypeId const comparable #142789
+338
−145
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
rustbot
added
A-LLVM
|
Some changes occurred to the intrinsics. Make sure the CTFE / Miri interpreter 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 Some changes occurred in compiler/rustc_codegen_gcc |
This comment has been minimized.
This comment has been minimized.
Noratrieb
reviewed
Jun 21, 2025
oli-obk
force-pushed
the
constable-type-id
branch
from
3cddd21 to
1fd7b66
Compare
This comment has been minimized.
This comment has been minimized.
|
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 Also, I am definitely not comfortable landing this by myself, I can only review the const-eval parts. Changing the representation of |
|
Some changes occurred in compiler/rustc_codegen_ssa |
|
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 |
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 |
This comment has been minimized.
This comment has been minimized.
antoyo
reviewed
Jun 21, 2025
bjorn3
reviewed
Jun 21, 2025
jdonszelmann
added a commit
to jdonszelmann/rust
that referenced
this pull request
Jun 23, 2025
Make `PartialEq` a `const_trait` r? `@fee1-dead` or `@compiler-errors` something generally useful but also required for rust-lang#142789
jdonszelmann
added a commit
to jdonszelmann/rust
that referenced
this pull request
Jun 23, 2025
Make `PartialEq` a `const_trait` r? ``@fee1-dead`` or ``@compiler-errors`` something generally useful but also required for rust-lang#142789
|
☔ The latest upstream changes (presumably #142906) made this pull request unmergeable. Please resolve the merge conflicts. |
oli-obk
force-pushed
the
constable-type-id
branch
2 times, most recently
from
b8a7a10 to
1c47a64
Compare
bjorn3
reviewed
Jun 24, 2025
| @@ -175,6 +175,17 @@ pub(crate) fn codegen_const_value<'tcx>( | |||
| fx.module.declare_data_in_func(data_id, &mut fx.bcx.func); | |||
| fx.bcx.ins().global_value(fx.pointer_type, local_data_id) | |||
| } | |||
| GlobalAlloc::Type { .. } => { | |||
| let data_id = data_id_for_alloc_id( | |||
There was a problem hiding this comment.
data_id_for_alloc_id won't work as that pushes a TodoItem::Alloc, but you aren't handling GlobalAlloc::Type in define_all_allocs. That is why I suggested copying and adapting data_id_for_vtable.
There was a problem hiding this comment.
Ah I thought the vtable thing was because there was some lifetime erasing going on
This comment has been minimized.
This comment has been minimized.
oli-obk
force-pushed
the
constable-type-id
branch
from
1c47a64 to
bcb4aa2
Compare
|
The job Click to see the possible cause of the failure (guessed by this bot) |
bjorn3
reviewed
Jun 24, 2025
| @@ -471,6 +490,8 @@ fn define_all_allocs(tcx: TyCtxt<'_>, module: &mut dyn Module, cx: &mut Constant | |||
| .principal() | |||
| .map(|principal| tcx.instantiate_bound_regions_with_erased(principal)), | |||
| ), | |||
| // TODO | |||
| GlobalAlloc::Type { .. } => todo!(), | |||
There was a problem hiding this comment.
This needs a data_id_for_ty call.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This should unblock stabilizing const
TypeId::ofand allow us to progress into any possible future we want to takeTypeIdto.To achieve that
TypeIdnow contains16 / size_of<usize>()pointers which each are actually justsize_of<usize>()bytes of the stable hash. At compile-time these pointers cannot be dereferenced or otherwise inspected (at present doing so might ICE the compiler). Preventing inspection of this data allows us to refactorTypeIdto any other scheme in the future without breaking anyone who was tempted to transmuteTypeIdto 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).
const fntype_id#77125r? @RalfJung