apply_member_constraints: fix placeholder check

[lcnr]

Checking whether the member region is an existential region from a higher universe is just wrong and I am pretty sure we've added that check by accident as the naming was just horribly confusing before #140466.

I've encountered this issue separately while working on #139587, but feel like it's probably easier to separately FCP this change. This allows the following code to compile

trait Proj<'a> {
    type Assoc;
}
impl<'a, 'b, F: FnOnce() -> &'b ()> Proj<'a> for F {
    type Assoc = ();
}

fn is_proj<F: for<'a> Proj<'a>>(f: F) {}
fn define<'a>() -> impl Sized + use<'a> {
    // This adds a use of `opaque::<'a>` with hidden type `&'unconstrained_b ()`.
    // 'unconstrained_b is an inference variable from a higher universe as it gets
    // created inside of the binder of `F: for<'a> Proj<'a>`. This previously
    // caused us to not apply member constraints. We now do, constraining
    // it to `'a`.
    is_proj(define::<'a>);
    &()
}

fn main() {}

This should not be breaking change, even in theory. Applying member constraints is incomplete in rare circumstances which means that applying them in more cases can cause spurious errors, cc #140569/#142073. However, as we always skipped these member regions in apply_member_constraints the skipped region is guaranteed to cause an error in check_member_constraints later on.

[rustbot]

r? @oli-obk

rustbot has assigned @oli-obk.
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

[lcnr]

@rfcbot fcp merge

[rfcbot]

Team member @lcnr has proposed to merge this. The next step is review by the rest of the tagged team members:

• @BoxyUwU
• @compiler-errors
• @jackh726
• @lcnr
• @nikomatsakis
• @oli-obk
• @spastorino

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[jackh726]

This comment is weird: "It is totally acceptable ... as long as they don't actually do so"?

[lcnr]

"to be able to" vs "to do"

As in: it's fine for the member region to be an existential region created in a higher universe, as long as it doesn't actually name any placeholder from that higher universe.

How would you restructure this comment? Is the following clearer?

It is totally acceptable for member regions to be able to name placeholders from higher universes, as long as they don't actually refer to a placeholder.

[jackh726]

it's fine for the member region to be an existential region created in a higher universe, as long as it doesn't actually name any placeholder from that higher universe.

This is the most clear

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[nikomatsakis]

@rfcbot reviewed

That example is pretty mind-binding -- the key thing that took me a while to understand was that the universal variable created by proving for<'a> Proj<'a> is not the thing you are talking about which gets constrained by 'a -- it is rather the extra 'b that appears in the self type. OK.

[lcnr]

Suggested change

	// compiled as it simnply didn't define the hidden type of
	// compiled as it simply didn't define the hidden type of