Skip to content
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

Closed
wants to merge 1 commit into from

Conversation

nbdd0121
Copy link
Contributor

Since comparison on DynMetadata doesn't yield much information, remove (Partial)?(Eq|Ord) and Hash from DynMetadata.

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

@rustbot
Copy link
Collaborator

rustbot commented May 28, 2023

r? @thomcc

(rustbot has picked a reviewer for you, use r? to override)

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-libs Relevant to the library team, which will review and decide on the PR/issue. T-lang Relevant to the language team, which will review and decide on the PR/issue. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. labels May 28, 2023
@rust-log-analyzer

This comment has been minimized.

@thomcc
Copy link
Member

thomcc commented May 29, 2023

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

@rustbot rustbot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels May 29, 2023
@@ -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>() {
Copy link
Member

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

Copy link
Member

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.

Copy link
Member

@BoxyUwU BoxyUwU May 29, 2023

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

Copy link
Member

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.

Copy link
Member

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

Copy link
Contributor Author

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.

Copy link
Member

@pnkfelix pnkfelix Aug 30, 2023

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?

Copy link
Member

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)?

@BoxyUwU
Copy link
Member

BoxyUwU commented May 29, 2023

Is == for raw pointers implemented as a buitlin impl? this PR doesnt make it impossible to == or change the Eq impl for raw pointers so why are you removing Eq from metadata which should be required in order to == raw pointers. You're removing bounds from Metadata but still acting as if all metadata can be hashed and eq'd. Tbh this PR seems like its going to be a future compat hazard and a soundness hazard

@nbdd0121
Copy link
Contributor Author

The == of raw pointer is builtin.

We can't remove PartialEq/Eq/Hash on dyn trait pointers anymore because that'll break backward compatibility. The point of this PR is to prevent us continuing our mistakes for ptr metadata API; we can still change it while it's unstable.

@BoxyUwU
Copy link
Member

BoxyUwU commented May 30, 2023

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.

@nbdd0121
Copy link
Contributor Author

No, not hashing/eq them will make it behave as if they are always equal.

@BoxyUwU
Copy link
Member

BoxyUwU commented May 31, 2023

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

@Dylan-DPC
Copy link
Member

r? compiler

@rustbot rustbot assigned TaKO8Ki and unassigned thomcc Aug 15, 2023
@Dylan-DPC Dylan-DPC added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Aug 15, 2023
@thomcc
Copy link
Member

thomcc commented Aug 28, 2023

I don't know who should review this but it shouldn't be me. It's probably t-lang.

r? lang

@rustbot rustbot assigned pnkfelix and unassigned thomcc and TaKO8Ki Aug 28, 2023
@pnkfelix
Copy link
Member

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

@rustbot rustbot added the S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. label Aug 30, 2023
@rustbot rustbot removed the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Aug 30, 2023
@Dylan-DPC
Copy link
Member

@nbdd0121 any updates on this?

@Dylan-DPC
Copy link
Member

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

@Dylan-DPC Dylan-DPC closed this Mar 15, 2024
@Dylan-DPC Dylan-DPC added S-inactive Status: Inactive and waiting on the author. This is often applied to closed PRs. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Mar 15, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-inactive Status: Inactive and waiting on the author. This is often applied to closed PRs. T-lang Relevant to the language team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants