for<'a> &'a T: 'a and closures regressed

[nikomatsakis]

In #98109, we fixed some bugs relating to NLL and for but apparently regressed a few examples. There are two tests in the test suite:

• collectivity-regression.rs
• snocat-regression.rs

[aliemjay]

#96899 is the root cause of these regressions:

• Check that closures satisfy their where bounds #96899 introduced the regressions.
• Remove migrate borrowck mode #95565 fixed the regressions, but the fix was unsound.
• fix universes in the NLL type tests #98109 fixed the unsoundness in NLL; they regressed again.

Note that both regressed crates are on nightly, but the repro can use stable for both.

@rustbot label regression-from-stable-to-nightly C-bug T-compiler

[jackh726]

Okay, so timeline is:
1.61 -> pass
#96899 -> fail
1.62 cutoff
#95565 -> pass
#98109 -> fail

If we revert #96899, do they get fixed with remaining changes still in place?

edit: The problem is #96899 landed in beta and these pass there?

[compiler-errors]

@jack726 we reverted #96899 on beta (#97642), so the earliest #96899 is landing is 1.63

[aliemjay]

If we revert #96899, do they get fixed with remaining changes still in place?

I think yes. I'll check when I have time.

[jackh726]

@jack726 we reverted #96899 on beta (#97642), so the earliest #96899 is landing is 1.63

Ah right. Well that explains things. Sounds like we need to think about this again (if another beta revert, or full revert, is warranted)

[apiraino]

If it's ok, I'm going to nominate this issue for the T-compiler meeting for a discussion about reverting multiple PRs related to NLL, seems there are many bits involved.

@rustbot label +I-compiler-nominated

[apiraino]

Issue discussed by T-compiler on Zulip, adding their notes, opinion was that there's no need revert.

(Also, the Types team had a discussion about this issue)

@rustbot label -I-compiler-nominated

[apiraino]

WG-prioritization assigning priority (Zulip discussion).

@rustbot label -I-prioritize +P-critical

[apiraino]

Revisited during T-compiler meeting (Zulip discussion), downgrading priority since it has been decided this is an acceptable breakage.

@rustbot label +P-high -P-critical

[jackh726]

We discussed this a bit in the t-types meeting today.

We basically concluded (as has already really been said a few times in a couple places) that #96899 was a soundness fix and not worth reverting for this regression. Also, the regression is small, weird enough, and has an easy fix; so, it's likely not worth investing time trying to dig into a fix. Especially given this will be "fixed" at some point in the future anyways by a better HRTB implied bounds story.

[pnkfelix]

reassigning to T-types on basis that the eventual plan for fixing this is tied to a better HRTB implied bounds story.

@rustbot label: -T-compiler +T-types

[pnkfelix]

If I understand correctly, this was first going to affect 1.62, but then we reverted PR #97642 solely for the 1.62.* release, and thus it affected 1.63.0 (which just was released today).

Thus, this has not been a stable-to-nightly regression for several weeks, it has been a stable-to-beta regression, and as of today it is a stable-to-stable regression.

@rustbot label: -regression-from-stable-to-nightly +regression-from-stable-to-stable