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

Incremental compilation breaks trait objects in async fns #66814

Closed
vojtechkral opened this issue Nov 27, 2019 · 3 comments

Comments

@vojtechkral
Copy link
Contributor

@vojtechkral vojtechkral commented Nov 27, 2019

Hi,
my colleague @Wenceslaw stumbled upon a strange problem when comparing Arc pointers equality. It seems that when constructing trait objects in async functions, sometimes the vtable pointer is different even though the type is the same, leading to Arc::ptr_eq() returning false.

I've put together a minimal-ish example: playground link.

Through some experimentation I've found out the problem occurs when incremental compilation is turned on. On the playground it's off, so you don't see a problem there, but with incremental on, I get an output like this:

[src/main.rs:30] Arc::ptr_eq(&xxx.clone(), &xxx.clone()) = true
[src/main.rs:22] Arc::ptr_eq(&(self.clone() as Arc<dyn Trait>), &other) = true
[src/main.rs:23] fmt_fat_ptr(&*self) = "(55c300209b50, 55c2fe990ea0)"
[src/main.rs:24] fmt_fat_ptr(&*other) = "(55c300209b50, 55c2fe990ea0)"
[src/main.rs:36] Arc::ptr_eq(&xxx.clone(), &xxx.clone()) = true
[src/main.rs:22] Arc::ptr_eq(&(self.clone() as Arc<dyn Trait>), &other) = false
[src/main.rs:23] fmt_fat_ptr(&*self) = "(55c300209b50, 55c2fe990ea0)"
[src/main.rs:24] fmt_fat_ptr(&*other) = "(55c300209b50, 55c2fe991050)"

Toolchain version and optimization level doesn't seem to make any difference.

cc @janbraiins

(edit: typos)

@vojtechkral vojtechkral changed the title Incremental compilation breaks trait objects Incremental compilation breaks trait objects in async fns Nov 27, 2019
@jonas-schievink

This comment has been minimized.

Copy link
Member

@jonas-schievink jonas-schievink commented Nov 27, 2019

Ah, this isn't a bug. We do not guarantee that vtables get deduplicated, so there might be as many as rustc feels like creating in any given executable or library.

@vojtechkral

This comment has been minimized.

Copy link
Contributor Author

@vojtechkral vojtechkral commented Nov 27, 2019

@jonas-schievink Ok, but isn't it a bit weird that Arc::ptr_eq's usefulness depends on compiler's mood? The documentation says:

Returns true if the two Arcs point to the same value (not just values that compare as equal).

@vojtechkral

This comment has been minimized.

Copy link
Contributor Author

@vojtechkral vojtechkral commented Nov 27, 2019

Seems like this is the same issue as #63021

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.