Fix ICE: Restrict param constraint suggestion

[estebank]

When encountering an associated item with a type param that could be constrained, do not look at the parent item if the type param comes from the associated item.

Fix #117209, fix #89868.

[rustbot]

r? @petrochenkov

(rustbot has picked a reviewer for you, use r? to override)

[matthiaskrgr]

Does that also fix #89868 ?

[lqd]

It seems unlikely that it would 😅

[matthiaskrgr]

my disappointment is immeasurable and my day is ruined

[estebank]

@matthiaskrgr it does now.

[lqd]

A masterful move, unruining Matthias' day :)

[compiler-errors]

I feel like this is not the right way of fixing this bug?

Why do we allow Self constructors from outer items that reference parameters that aren't in scope anyways? Like, we're referencing a type parameter that doesn't exist here, right?

I feel like this also may cause strange behavior (or unsoundness? not exactly sure, depends on when we compare params by name or by index) when we actually do have a substitutable param here:

use std::marker::PhantomData;

struct S0<T>(PhantomData<T>);

impl<T> S0<T> {
    fn foo() {
        fn bar<T2>() -> S0<T2> {
            Self(PhantomData) // <~ this constructs S0<T> not S0<T2> :(
        }
    }
}

cc @cjgillot who tried this and had to unland it in #111557

[petrochenkov]

#111020 was reverted due to a regression, but it was probably a right thing to do in general.

Maybe we should do the usual bugfix process with a crater run, deprecation lint, and a tracking issue here.
In the meantime this PR could be merged to avoid the ICE.

[petrochenkov]

#111020 was reverted due to a regression, but it was probably a right thing to do in general.

Maybe we should do the usual bugfix process with a crater run, deprecation lint, and a tracking issue here.
In the meantime this PR could be merged to avoid the ICE.

[petrochenkov]

@bors r+

[bors]

📌 Commit 7449478 has been approved by petrochenkov

It is now in the queue for this repository.