New solver: assert that normalizes-to hack RHS is always constrained after eval#109583
New solver: assert that normalizes-to hack RHS is always constrained after eval#109583compiler-errors wants to merge 1 commit intorust-lang:masterfrom
Conversation
rustbot
added
S-waiting-on-review
|
Some changes occurred to the core trait solver cc @rust-lang/initiative-trait-system-refactor |
| // However it is important not to unconditionally replace the rhs with a new infer var | ||
| // as otherwise we may replace the original unconstrained infer var with a new infer var | ||
| // and never propagate any constraints on the new var back to the original var. |
There was a problem hiding this comment.
I'm not sure if this ever matters in practice?
Or to put it in another perspective, if this indeed does matter, I don't understand why it's then valid to replace a constrained RHS with a fresh var here without later equating that constrained RHS against that var.
| }); | ||
|
|
||
| // NOTE: This term should never be considered unconstrained, not least due to the fact | ||
| // that the universe index has been bumped up at least once by `evaluate_goal` above. |
There was a problem hiding this comment.
why does evaluate_goal bump the universe index/alternatively is term_is_fully_unconstrained too pessimistic?
this is worrying to me.
I guess maybe we should change that code to replace the rhs with a new infer var, call evaluate_goal for the normalizes_to hack and then emit add an eq goal for the inference vars or sth? that feels safer to me 🤔
There was a problem hiding this comment.
I guess maybe we should change that code to replace the rhs with a new infer var, call evaluate_goal for the normalizes_to hack and then emit add an eq goal for the inference vars or sth? that feels safer to me
yeah i can do that, i have a branch that does that and coincidentally the code actually gets a bit cleaner too...
|
@rustbot author |
rustbot
added
S-waiting-on-author
…-2, r=lcnr,BoxyUwU Freshen normalizes-to hack goal RHS in the evaluate loop Ensure that we repeatedly equate the unconstrained RHS of the normalizes-to hack goal with the *actual* RHS of the goal, even if the normalizes-to goal loops several times and thus we replace the unconstrained RHS var repeatedly. Alternative to rust-lang#109583.
…-2, r=lcnr,BoxyUwU Freshen normalizes-to hack goal RHS in the evaluate loop Ensure that we repeatedly equate the unconstrained RHS of the normalizes-to hack goal with the *actual* RHS of the goal, even if the normalizes-to goal loops several times and thus we replace the unconstrained RHS var repeatedly. Alternative to rust-lang#109583.
4 participants
See
NOTEbelow, thethen_somebranch should never occur in practice.r? @BoxyUwU