Make TypeId const comparable #142789
Make TypeId const comparable #142789
Conversation
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.
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.
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
|
☔ 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
This comment has been minimized.
This comment has been minimized.
oli-obk
force-pushed
the
constable-type-id
branch
from
1c47a64 to
bcb4aa2
Compare
This comment has been minimized.
This comment has been minimized.
if we have a Both solutions 1 & 2 contain an AllocId that just gives me the right information straight away, but I can also just fill in a hash map whenever const eval invokes |
| } | ||
| GlobalAlloc::Static(def_id) => { | ||
| assert!(self.tcx.is_static(def_id)); | ||
| assert!(!self.tcx.is_thread_local_static(def_id)); | ||
| self.get_static(def_id) | ||
| } | ||
| GlobalAlloc::Type { ty, segment } => { |
There was a problem hiding this comment.
This code path ignores the pointer offset. Should probably error if it is not 0 instead of silently allowing people to offset it as they want without that actually doing anything
There was a problem hiding this comment.
or we add the offset to the hash value, which is technically what was done by the user
oli-obk
force-pushed
the
constable-type-id
branch
from
9009013 to
79fa8f8
Compare
…itly deciding not to
This comment has been minimized.
This comment has been minimized.
So suddenly the scope creeped from just supporting type_id comparison to full compile-time reflection? That's a completely different beast and requires a lot of design still, and nothing in the PR description or prior discussion prepared me for any sort of involvement of reflection in this change. I'd prefer to focus on one thing at a time... or at least, I'd like to know all relevant design goals before being asked to review a design.^^ If this must also provide reflection, we have to go back to square 0 and think about principled solutions. I still don't like the hacks here... but I'll wait for a complete description of the design goals to avoid being surprised with more previously unmentioned constraints again.^^ |
This comment has been minimized.
This comment has been minimized.
|
That's why this design is forward compatible to anything we want to do without affecting the runtime layout. I don't want to scope creep either XD |
|
I don't want to leave TypeId in limbo state while we figure out the entire design space of everything we ever want from it. I would rather put it into a state that is strictly forward compatible with anything we could want, thus this PR. |
|
I wouldn't mind that if there was some beautiful solution that also happened to be good for reflection -- but I don't think the solution in this PR qualifies as "beautiful". And I'd rather not have tricky hacks in the compiler that are motivated by speculative future extensions. We can always add these hacks later if it turns out that we really do want to make So for the sake of avoiding XY-like situations, I'd really appreciate if you could spell out the motivation of a tricky, non-obvious change like this in full upfront, rather than revealing it piecewise during the discussion. Being aware of your future plans now, here's another possible proposal:
I'm honestly still not super happy with that proposal, but you seem set on doing something along these lines and this is a compromise that I think I can live with, if it doesn't turn out to have unexpected problems. This will still require a bunch of special hacks to make these "allocations" have a known-0 base address, but I can't think of a better way (making the base address be the hash is not better, IMO). The proposal has one upside compared to item 3 in my previous list, which is that the opsem for |
Fair. Tho the idea that we can (ab)use this for reflection came independently from this design. The motivation was indeed just to get this stabilized, and since the cost seemed small to me with this PR I assumed option 3 was irrelevant |
If we're exposing any bytes to const eval, we can just expose everything and revisit adding provenance when T-lang approves a reflection experiment. I'll create a separate PR for just making the PartialEq impl const and propose moving TypeId to stabilization along with stabilizing the const trait impl without stabilizing const traits in general |
Having provenance on some bytes still means we'd appropriately error out if someone just transmutes the entire thing to |
|
I meant more in the sense of "Ralf is happy with this approach" XD I would prefer to prevent such transmutes failing by having provenance $somewhere, so I'll stop talking myself out of it now 😆 |
oli-obk
force-pushed
the
constable-type-id
branch
from
afa74de to
6fea6c3
Compare
|
The Miri subtree was changed cc @rust-lang/miri |
This comment has been minimized.
This comment has been minimized.
oli-obk
force-pushed
the
constable-type-id
branch
from
6fea6c3 to
2e8cece
Compare
|
The job Click to see the possible cause of the failure (guessed by this bot) |
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