Repository navigation
NLL: turn off migration mode #58781
Description
Transition fully to NLL (instead of the migration mode currently used).
- one currently opts into this via
#![feature(nll)]or-Z borrowck=mir - It gets rid of AST-region inference errors, causing some code to be accepted that is rejected by migrate mode, and changing diagnostics in many cases.
- Potential blockers:
- ~NLL-sound bugs that affect NLL mode without migration
NLL accepts higher-ranked subtype that non-NLL rejects #57642 (needs test for now)
- Diagnostic differences
- Migrate compare-mode=NLL test differences to revisions (to ease stabilization PR and meticulously check diagnostic differences)
Two-phase borrows (2PB) question: [NLL] prohibit "two-phase borrows" with existing borrows? #56254Must have crater run showing no major crates fail in practice (crater run to estimate impact of full NLL transition #60680)- coercion becomes order dependent for higher-ranked functions #73154
- Likely needs changes to the leak check
Investigate [NLL] Lifetimes errors in a function can mask later errors in same function #96331- Diagnostics-only change, should be fine
- ~NLL-sound bugs that affect NLL mode without migration
Activity
pnkfelix commentedon Feb 27, 2019
Explicitly marking this P-medium for now, to reflect the fact that transitioning the 2015 edition to migrate mode is higher priority for the short term.
Auto merge of #59114 - matthewjasper:enable-migate-2015, r=pnkfelix
Auto merge of #59114 - matthewjasper:enable-migate-2015, r=pnkfelix
nikomatsakis commentedon May 9, 2019
Created #60680 as an issue to do a first crater run to get a rough idea.
jethrogb commentedon May 10, 2019
Is this the right place for comments/questions about the migration warning?
I got this warning:
The warning is good, my code definitely has UB. I found that I can't upgrade the warning to an error with
deny/forbid(warnings). Why is that?This code compiles and has UB on Rust 1.0, I thought NLL is only supposed to relax things? Are you still fixing any bugs in the old borrow checker?
pnkfelix commentedon May 13, 2019
@jethrogb no, NLL was not meant to solely relax things. Such relaxation is the primary selling point of NLL, but we always knew it was going to introduce breakage.
The shift to NLL is coupled with a change in the underlying borrow-checker implementation to analyze MIR (instead of analyzing the higher-level AST, which is what the old borrow checker did). In order to avoid injecting breaking changes that people could not work around in the short term, we currently have NLL in a migration mode. That was added in PR #52681.
In hindsight, it may have been nice to leverage the lint system here to let people upgrade these warnings to errors. (One reason we didn't do that is that we didn't want people to
#![allow(..)]the warnings here. For more on that, see also issue #34596 and PR #59658.)Rollup merge of rust-lang#63230 - tmandry:disallow-possibly-uninitial…
Rollup merge of rust-lang#63230 - tmandry:disallow-possibly-uninitial…
18 remaining items
lqd commentedon Jun 23, 2021
Sorry, I meant I had already rebased your branch in the link above: it was indeed in slow-moving parts of the compiler, with only a few simple conflicts, and only one compile error. Very straightforward to update overall.
Your improvements to these error messages are already looking great. I can open a PR and help land them, if @nikomatsakis and @Aaron1011 want to have a look ?
Aaron1011 commentedon Oct 2, 2021
Now that higher-ranked subtype errors are improved for stable code (#57374 (comment)), is #73154 the only blocker?
lqd commentedon Oct 2, 2021
A few ideas:
mutable_borrow_reservation_conflictlint from Tracking issue formutable_borrow_reservation_conflictcompatibility lint #59159 to turn NLLs on ?nikomatsakis commentedon Oct 4, 2021
Regarding the leak check:
I believe we do have to reproduce some of that functionality.
marmeladema commentedon Mar 31, 2022
Is there something actionable that a small contributor like me could help with? It would be very pleasant to finally stabilize NLL 🥳
bstrie commentedon Mar 31, 2022
@marmeladema The diagnostic issues mentioned above could probably use triage to see if they're still relevant: https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Aissue+label%3ANLL-diagnostics . If they are, then resolving those may be a good place to start. You can also try hopping into #t-compiler or #t-compiler/help and asking there.
marmeladema commentedon Apr 1, 2022
I opened a zulip threads in the wg-nll group about those: https://rust-lang.zulipchat.com/#narrow/stream/122657-t-compiler.2Fwg-nll/topic/nll.20diagnostics.20issues
TL;DR is that there are actually 4 and we believe they can all probably be closed.
jackh726 commentedon May 5, 2022
I've updated the op to include the latest potential blockers and added a tracking label to reflect that some impl work needs to be re. #73154.
m-ou-se commentedon May 17, 2022
Do we know why turning off migration mode fixes #95527?
Is that something that can be fixed without having to wait for turning off migration mode (to not block scoped threads on #73154)?
jackh726 commentedon May 17, 2022
I'm not sure. Let's see if I can take a decent stab at #73154 before trying to dig into #95527. (It's likely that any fix for #95527 will be just as complex (if not more) than just fixing #73154)
Auto merge of rust-lang#95565 - jackh726:remove-borrowck-mode, r=niko…