Incremental compilation breaks trait objects in async fns

[vojtechkral]

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)

[jonas-schievink]

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]

@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]

Seems like this is the same issue as #63021