Fix ICE in deny_equality_constraints with bare qualified self types

[lapla-cogito]

close #152338

When processing equality constraints in where clauses like <T>::Item = T, the compiler would panic with an index underflow. This occurred because deny_equality_constraints assumed that qualified paths always include a trait (e.g., <T as Foo>::Bar), but <T>::Item has no trait part (qself.position == 0). After removing the associated type segment, the path becomes empty, causing underflow in segments.len()-1 in here.

I think this can be prevented by checking the value of qself.position, similar to how it's handled in rustc_resolve/src/late.rs:

rust/compiler/rustc_resolve/src/late.rs

Lines 4748 to 4750 in be4794c

	// This is a case like `<T>::B`, where there is no
	// trait to resolve. In that case, we leave the `B`
	// segment to be resolved by type-check.

[rustbot]

r? @mati865

rustbot has assigned @mati865.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: compiler
• compiler expanded to 21 candidates
• Random selection from 12 candidates

[fmease]

For T: Trait, <T>::AssocTy = () we should be able to yield the same suggestion as for T: Trait, T::AssocTy = (). So, instead of bailing out you could handle the case if you want to.

[lapla-cogito]

Neat, thanks for the suggestion! Implemented in here: fd7cadd .

[rustbot]

Reminder, once the PR becomes ready for a review, use @rustbot ready.

[Zalathar]

What’s the background leading to this PR?

I’m worried that it’s a machine-generated change, with little or no human understanding behind it.

[lapla-cogito]

@Zalathar Do you believe this modification is inappropriate? (If so, I apologize—it simply reflects my incomplete understanding.) Regardless, IIUC, the background for this ICE is as follows: (This expands on the information provided in the PR's description.)

In cases like <T>::Item=RhsTy, when extracting the associated type segment, only the associated type name is included without the trait name. That is, full_path.segments = ["Item"] and qself.position = 0. Consequently, at line 1846, full_path.segments[qself.position..] evaluates to ["Item"], and inside the branch, assoc_path.segments.pop() causes assoc_path to become empty. When computing len on such an empty assoc_path, the result is naturally 0, causing an underflow when calculating len - 1 at here. This then leads to an ICE when accessing the array at here.

[lapla-cogito]

However, I'm not very experienced in creating proper suggestions as mentioned above, so I may need some time to verify my implementation works well, which might delay when I can push a new version.

[lapla-cogito]

@rustbot ready

[fmease]

I'm very sorry for the delay.

A lot of this code may soon go away depending on if #153513 (or rather a more drastic version of it that removes most code related to equality predicates) gets waved through.

Let's block this PR on it. It might get accepted or rejected soon.
@rustbot blocked

[rust-bors]

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

[fmease]

As announced, this has been superseded by #153513. I'm now going to close this PR, thanks a lot for your contribution and your understanding.