Skip to content

New solver: assert that normalizes-to hack RHS is always constrained after eval #109583

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 1 commit into from
Closed

New solver: assert that normalizes-to hack RHS is always constrained after eval #109583

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
19 changes: 8 additions & 11 deletions compiler/rustc_trait_selection/src/solve/eval_ctxt.rs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -285,18 +285,15 @@ impl<'a, 'tcx> EvalCtxt<'a, 'tcx> {
// The rhs of this `normalizes-to` must always be an unconstrained infer var as it is
// the hack used by `normalizes-to` to ensure that every `normalizes-to` behaves the same
// regardless of the rhs.
//
// 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.
Comment on lines -289 to -291
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

let term = this
.term_is_fully_unconstrained(goal)
.then_some(goal.predicate.term)
.unwrap_or_else(|| {
this.next_term_infer_of_kind(goal.predicate.term)
});

// 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.
Copy link
Contributor

@lcnr lcnr Mar 27, 2023 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 🤔

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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...

// Or if this assertion ever fails, at least we have a useful test case :^)
assert!(!this.term_is_fully_unconstrained(goal));

let fresh_term = this.next_term_infer_of_kind(goal.predicate.term);
let projection_pred = ty::ProjectionPredicate {
term,
term: fresh_term,
projection_ty: goal.predicate.projection_ty,
};
new_goals.normalizes_to_hack_goal =
Expand Down