Inconsistent/wrong choice of trait impls under miri
with transmuted vtables
#135230
Labels
A-miri
Area: The miri tool
A-trait-objects
Area: trait objects, vtable layout
C-bug
Category: This is a bug.
I-ICE
Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️
needs-triage
This issue may need triage. Remove it if it has been sufficiently triaged.
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
Here is a test case
(playground)
When run normally, this prints
When run with miri, this prints
Expected behavior: Miri either reports UB, or behaves the same way like the actual codegen does.
It gets even more interesting if we add a trait bound to the
impl
:(playground)
When run normally, this prints
When run with miri, this prints
Oh wonderful, the type apparently just changes in the middle of it!
If we add a second implementation, Miri reconsiders its choices
(playground)
(Behavior when run normally: unchanged.)
When run with miri, this prints
(still wrong though / [actual execution without
miri
is reportingMarker1
,Marker1
])This behavior must come from some sort of rough heuristic that wasn't supposed to ever matter… because… if the second
impl
exists but comes with an impossible trait bound, then miri still seems to try to make use of thisMarker2
-impl nonetheless:(playground)
When run normally, this still prints
When run with miri, you get ICE:
To run into this ICE, calling a method of
Bound
isn't actually necessary. Once they.report()
call it reached, it already goes ICE:(playground)
@rustbot label A-miri, A-trait-objects, I-ICE, T-compiler
The text was updated successfully, but these errors were encountered: