Uh oh!
There was an error while loading. Please reload this page.
introduce "type must be valid for" into lexical region solver - #55988
introduce "type must be valid for" into lexical region solver#55988nikomatsakis wants to merge 6 commits into
Conversation
eddyb
commented
Nov 15, 2018
@bors r+ |
bors
commented
Nov 15, 2018
📌 Commit 4b4e074fdc64cc1e189ae86a813f0c30cb8ab337 has been approved by |
nikomatsakis
commented
Nov 15, 2018
cc @rust-lang/compiler -- I'm nominating this for beta backport, since it fixes a regression. |
rust-highfive
commented
Nov 15, 2018
The job Click to expand the log.I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
emilyalbini
commented
Nov 15, 2018
@bors r- |
nikomatsakis
commented
Nov 16, 2018
@bors r=eddyb p=1 |
bors
commented
Nov 16, 2018
📌 Commit 134c7d1019623aaa96f92d574428303845474fd4 has been approved by |
nikomatsakis
commented
Nov 16, 2018
Giving p=1 because this is a Rust 2018 blocker. |
nikomatsakis
commented
Nov 16, 2018
@bors r- Huh. Apparently this broke some tests. |
rust-highfive
commented
Nov 16, 2018
The job Click to expand the log.I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
nikomatsakis
commented
Nov 16, 2018
OK, so, the errors are sort of interesting. These are test cases that also break with NLL (I guess that makes sense). They have to do with closures whose signatures contain invalid types -- currently, regionck doesn't give an error for this, but it seems wrong. An example is: || {&mut x //~ ERROR cannot infer};Why, you ask, is this wrong? Well, the answer is that this is an I suspect we can get away with breaking these tests -- NLL will break them away, and they are seim-broken -- but it makes me a bit nervous. We could also try one of the alternative fixes I had in mind. (Hmm, I thought that the NLL breakage was noticed in the wild (#49824) but it turns out that this breakage was noticed by me from one of our other tests which was purposefully probing at extreme scenarios. That makes me feel better.) One test that used to give errors also now started to work, interestingly -- that test seems clearly "ok" to me (it's an |
nikomatsakis
commented
Nov 16, 2018
On balance, given that the broken tests are basically invalid and the fixed test seems valid, I'm inclined to run with it. |
rust-highfive
commented
Nov 16, 2018
The job Click to expand the log.I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
rust-highfive
commented
Nov 16, 2018
The job Click to expand the log.I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
nikomatsakis
commented
Nov 18, 2018
@bors r=eddyb |
bors
commented
Nov 18, 2018
📌 Commit 752feb7814fd98c383c344dccb6cd9c328fbcf5e has been approved by |
752feb7 to
29ec15aComparealexcrichton
commented
Nov 19, 2018
@nikomatsakis with #56043 landed and backported is still still 2018 edition critical? (aka on the milestone) |
nikomatsakis
commented
Nov 19, 2018
@alexcrichton it is not |
nikomatsakis
commented
Nov 19, 2018
@bors p=0 |
nikomatsakis
commented
Nov 21, 2018
@bors r=eddyb |
bors
commented
Nov 21, 2018
📌 Commit 29ec15a has been approved by |
nikomatsakis
commented
Nov 21, 2018
@bors r- Actually, second guessing. I want to think about whether to land this now or let NLL fix these test cases. |
TimNN
commented
Dec 4, 2018
Ping from triage @nikomatsakis: What is the status of this PR? |
bors
commented
Dec 7, 2018
☔ The latest upstream changes (presumably #56502) made this pull request unmergeable. Please resolve the merge conflicts. |
@nikomatsakis I'd like us to consider landing this now. Minimizing the number of subtle discrepancies between AST-borrowck and NLL simplifies our internal processes for evaluating the correctness of NLL itself. |
eddyb
commented
Dec 10, 2018
@pnkfelix I would prefer landing this if it gets us closer to removing the AST borrowck (is there a full post-2018 transition plan spelled out anywhere?). |
Dylan-DPC-zz
commented
Jan 7, 2019
ping from triage @nikomatsakis@pnkfelix@eddyb any updates on this? |
nikomatsakis
commented
Jan 7, 2019
Sorry, I've been busy. I'm going to try and rebase this and/or close it this week though =) |
stokhos
commented
Jan 14, 2019
Ping from triage @nikomatsakis Have you been able to make any progress on this PR? |
nikomatsakis
commented
Jan 14, 2019
via email
Not yet but still hope to =) |
Centril
commented
Jan 27, 2019
Ping from triage, @nikomatsakis -- have you been able to make progress? r? @pnkfelix |
Dylan-DPC-zz
commented
Mar 11, 2019
ping from triage @nikomatsakis closing this due to inactivity. Thanks |
This is a fix for #55756 -- it makes the lexical region solver impose constraints more like the ones that NLL does, which overcomes a shortcoming in the logic for handling
<T as Foo<'a>>::Bar: 'boutlives bounds. As part of the NLL check, that logic itself was fixed to avoid "overconstraining" -- i.e., adding stricter region checks than were necessary. Unfortunately, the logic now has the potential to underconstrain (it always did, but it's worse). This is caused #55756. This change matches NLL's behavior, which winds up requiring that if a value of typeTis live during some scope S, then every region inTmust outliveS(which is stricter than outlives when normalization is involved).As part of the Chalk and Polonius work, I plan to revisit this whole system, and hopefully move to a more precise solver that can accommodate the kinds of outlives constraints we encounter in progress. However, this patch seems like a reasonably conservative step that also solves the regressions at hand.
More discussion in this comment.
Fixes#55756
r? @eddyb