member constraints are order-dependent #140569
Labels
A-impl-trait
Area: `impl Trait`. Universally / existentially quantified anonymous types with static dispatch.
A-NLL
Area: Non-lexical lifetimes (NLL)
C-bug
Category: This is a bug.
T-types
Relevant to the types team, which will review and decide on the PR/issue.
this fails with
We've got
'm member ['a, 'static]
and'm member ['b, 'static]
. The final region chosen for'm
depends on the order in which we apply these constraints:'m member ['b, 'static]
chooses'b
'm member ['a, 'static]
as'a: 'b
does not hold, this has to choose'static
'm = 'static
which satisfies both member constraintsand alternatively:
'm member ['a, 'static]
chooses'a
'm member ['b, 'static]
can still choose'b
as'b: 'a
holds'm = 'b
which means that'm member ['a, 'static]
does not holdFixing this is not too difficult, we can "simply" apply member constraints for each member region until we reach a fixpoint. I will implement this separately once #139587 landed.
The text was updated successfully, but these errors were encountered: