-
Notifications
You must be signed in to change notification settings - Fork 13.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove Hash, PartialEq, Eq, PartialOrd, Ord from DynMetadata #112052
Conversation
r? @thomcc (rustbot has picked a reviewer for you, use r? to override) |
This comment has been minimized.
This comment has been minimized.
r=me on the impl, I don't know who has to sign off for this to merge though (definitely someone other than me, perhaps it's already done? Not sure). Punting back to you to figure that out. @rustbot author |
@@ -960,17 +960,21 @@ mod impls { | |||
fn hash<H: Hasher>(&self, state: &mut H) { | |||
let (address, metadata) = self.to_raw_parts(); | |||
state.write_usize(address.addr()); | |||
metadata.hash(state); | |||
if mem::size_of_val(&metadata) == mem::size_of::<usize>() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
surely it would be better to just require metadata to be Hash
instead of special casing usize
size'd metadata via a transmute. this also means that we cannot have usize
sized metadata with padding it
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
doing this would make it extremely hard to ever support unsizing away arbitrary const generics with adt_const_params
since if you had a usize
size'd type for your const arg it would now implicitly get hashed whereas if you added a byte of padding you wouldnt.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Perhaps we could have a (private to core) intrinsic like type_id
that works for non 'static types that just returns bool
for whether the metadata here is a usize
instead of assuming that the only usize
size'd metadata we are ever going to have is a usize
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd be in favor of that, the impl is kind of gross as is.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess the metadata can also be pointers to vtables which would be usize
sized, is this supposed to affect those too? I guess the intrinsic would have to be more complex if so
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It'll be confusing to have DynMetadata
of the same type to hash to different values.
The impl here is essentially just going back to it's old state before we have the unstable ptr metadata API (the old one uses ptr casting while I chose to use transmute_copy, but the essence is the same).
One possible solution to avoid this is to have a private-to-core trait MetadataHash
that's implemented both for ()
, usize
and DynMetadata
, and we have that in the bound instead of Hash
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@nbdd0121 just so I'm clear: What is the longer-term goal w.r.t. to DynMetadata
(i.e. *dyn Trait` metadata i.e. pointers to vtables)?
My understanding is that this PR continues to hash them (by hashing their raw address, transmuted to a usize
), but it may be safer to exclude them, due to the issues pointed out in #106447 (comment) .
Excluding the metadata in that case will make hashes collide for two distinct &dyn Trait1
and &dyn Trait2
that has the same pointer address, but... I think that's acceptable?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It'll be confusing to have
DynMetadata
of the same type to hash to different values.
Also, I didn't understand what the "of the same type" was saying here. The same Type for distinct Trait1/Trait2? Or the same instance of the vtable (i.e. the same address)? Or the same Trait1 but distinct vtables (and thus the distinct hash values)?
Is |
The We can't remove |
How is it true that you can stop promising that metadata is Eq/Hash because the API is "unstable" when we stably expose that raw pointers are eq and hash for arbitrary metadata? The only way that makes any sense is if we are not hash/eq the metadata which is not what this PR is doing. |
No, not hashing/eq them will make it behave as if they are always equal. |
I don't think i really have the energy to continue this discussion. I don't particularly understand what you're saying either which is unfortunate. I'm not going to object to this PR since it would be unfair to argue this shouldn't land while also simaltaneously not being able to engage with it lol |
r? compiler |
I don't know who should review this but it shouldn't be me. It's probably t-lang. r? lang |
I'll be better able to review this once I get answers to #112052 (comment) @rustbot label: +S-waiting-on-author -S-waiting-on-review |
@nbdd0121 any updates on this? |
Closing this as inactive. Feel free to reöpen this pr or create a new pr if you get the time to work on this. Thanks |
Since comparison on
DynMetadata
doesn't yield much information, remove(Partial)?(Eq|Ord)
andHash
fromDynMetadata
.Since we currently allow unsized pointers to be hashed, this also involves changing the impl to preserve the current behaviour.
This idea was discussed briefly during last week's lang triage meeting.
cc #106447, @rust-lang/lang
@rustbot labels: +T-lang +T-libs-api