ICE upcasting or calling a supertrait method, for trait object with unfulfilled bound on generic argument #136492
Labels
A-trait-objects
Area: trait objects, vtable layout
C-bug
Category: This is a bug.
F-trait_upcasting
`#![feature(trait_upcasting)]`
I-ICE
Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️
P-low
Low priority
regression-from-stable-to-nightly
Performance or correctness regression from stable to nightly.
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
Original/first issue variant (using
trait_upcasting
)This (first) example for an ICE is broken out from the review of #135318, the PR after which it’s first appearing:
(playground)
The relevant subtle design/implementation point about trait objects is that upcasting them is (apparently) supported fully generically, for any
&dyn Trait<P>
type, even whenP: WithAssoc
isn’t met, even thoughTrait
itself as a trait does requireP: WithAssoc
. The new vtable-deduplication logic then wants to determine whether or notSupertrait<P::Assoc>
andSupertrait<()>
are the same&deduplicated; and the possibility thatP::Assoc
might be impossible to normalize during monomorphization never handled: withP = ()
above, which doesn’t implementWithAssoc
at all,<() as WithAssoc>::Assoc
can’t be normalized.Expected behavior: builds successfully; this was also the behavior on nightly until #135318 was merged
Actual behavior (since #135318 was merged):
(backtrace…)
@compiler-errors had already opened a PR with a possible fix, and it includes (a variant of) this test case.
@rustbot label A-trait-objects F-trait_upcasting
(deliberately no “requires-nightly” label, see next section)
Second issue variant (regression without unstable features)
Looking at the PR, it seems @compiler-errors has also identified that this ICEs from a method call, not just upcasting (as what the original repro did):
(playground)
(behavior: same as above, w.r.t expected behavior, regression point, and [similar] ICE message)
(backtrace…)
This means we do have an ICE regression on nightly without unstable features, which I don’t see tracked anywhere else yet (let's track this so it can't be forgotten, especially with the next beta cut coming up soon-ish).
The relevant subtle design/implementation point about trait objects is that a
&dyn Trait<P>
trait object will still be considered to implement all its supertraits, includingSupertrait<()>
in particular (so you can call its supertrait methods), even whenP: WithAssoc
doesn’t hold. For illustration, this variant offn call
also compiles:(and it can be used in the same way to now ICE)
@rustbot label regression-from-stable-to-nightly
The text was updated successfully, but these errors were encountered: