Generalize program clause for AliasEq goal with nested alias

[lowr]

Consider a goal: AliasEq(<<?0 as X>::A as Y>::B = <<?1 as X>::A as Y>::B). This is expected to (eventually) flounder when the traits are non-enumerable and the variables are yet to be known, but it's currently disproven:

1. the goal is canonicalized as follows:
   • forall<T, U> AliasEq(<<T as X>::A as Y>::B = <<U as X>::A as Y>::B)
2. we produce the following ProgramClause that could match:
   • forall<T, U, ..> AliasEq(<<T as X>::A as Y>::B = <<U as X>::A as Y>::B) :- AliasEq(..), AliasEq(..)
3. the consequence of the (instantiated) clause is unified with the goal, which produces a subgoal:
   • AliasEq(<<?0 as X>::A as Y>::B = <<?1 as X>::A as Y>::B)
   • this is because when we unify rhs of AliasEq, we see two AliasTys that we cannot unify structurally, forcing us to produce the subgoal
4. boom, cycle emerged, goal disproven!

The problem is that because we're reusing the original goal as the consequence of the program clause we expect them to unify structurally, however we cannot unify aliases structurally in general (e.g. <?0 as X>::A = <?1 as X>::A does not imply ?0 = ?1).

This PR solves it by placing a fresh variable in rhs of the consequence AliasEq instead of reusing the original term. This ensures that rhs of the original AliasEq goal is preserved via unification without producing subgoals even if it's an alias.

See rust-lang/rust-analyzer#14369 for a real world case where this issue arises.

[jackh726]

@bors r+

[bors]

📌 Commit db746e0 has been approved by jackh726

It is now in the queue for this repository.

[bors]

🔒 Merge conflict

This pull request and the master branch diverged in a way that cannot be automatically merged. Please rebase on top of the latest master branch, and let the reviewer approve again.

How do I rebase?

Assuming self is your fork and upstream is this repository, you can resolve the conflict following these steps:

1. git checkout fix/generalize-alias-alias-eq-clause (switch to your branch)
2. git fetch upstream master (retrieve the latest master)
3. git rebase upstream/master -p (rebase on top of it)
4. Follow the on-screen instruction to resolve conflicts (check git status if you got lost).
5. git push self fix/generalize-alias-alias-eq-clause --force-with-lease (update this PR)

You may also read Git Rebasing to Resolve Conflicts by Drew Blessing for a short tutorial.

Please avoid the "Resolve conflicts" button on GitHub. It uses git merge instead of git rebase which makes the PR commit history more difficult to read.

Sometimes step 4 will complete without asking for resolution. This is usually due to difference between how Cargo.lock conflict is handled during merge and rebase. This is normal, and you should still perform step 5 to update this PR.

Error message

Auto-merging tests/test/projection.rs
CONFLICT (content): Merge conflict in tests/test/projection.rs
Auto-merging chalk-solve/src/clauses.rs
Automatic merge failed; fix conflicts and then commit the result.

[bors]

☔ The latest upstream changes (presumably #780) made this pull request unmergeable. Please resolve the merge conflicts.

[jackh726]

@bors r+

[bors]

📌 Commit 91c24e3 has been approved by jackh726

It is now in the queue for this repository.

[bors]

⌛ Testing commit 91c24e3 with merge 88fd1c2...

[bors]

☀️ Test successful - checks-actions
Approved by: jackh726
Pushing 88fd1c2 to master...