-
Notifications
You must be signed in to change notification settings - Fork 12.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Want -Z borrowck=migrate
to test planning migration to non-lexical lifetimes
#46908
Comments
Actually I may have been overthinking this; that is may be no need to track error numbers. if we just track whether AST-borrowck signals any error at all (a mere boolean), then we can use this logic, I think:
|
@nikomatsakis and @pnkfelix recently discovered that we hadn't quite ironed out all the details here as much as @pnkfelix had thought. You can see discussion at: https://rust-lang.zulipchat.com/login/#narrow/stream/122657-wg-nll/subject/weekly.20meeting.20May.2029 (though I suppose you'll need to log into zulip to see it... maybe I'll transcribe the relevant portion to a gist or something publicly accessible...) |
I'm marking this as I-nominated for us to discuss in the meeting tomorrow. I think if we are going to get the Edition Preview out the door, we really need to see this get fixed. Here are some of the steps I think we need to take: Currently, when NLL is enabled, if we get "regionck errors", we supress them, but we issue a warning: rust/src/librustc/infer/error_reporting/mod.rs Lines 332 to 347 in b58b721
This was written before we trusted NLL. Now that we do, we should remove this warning. Next, we need to add a rust/src/librustc/session/config.rs Lines 453 to 458 in b58b721
and parse it: rust/src/librustc/session/config.rs Lines 2153 to 2158 in b58b721
The idea then is to make this mode act like
To make this work, we need to re-engineer the AST borrowck query so that it returns some kind of boolean indicating whether errors were reported. This is the query in question; it currently returns what rust/src/librustc_borrowck/borrowck/mod.rs Lines 89 to 90 in b58b721
Presently, we are actually always executing AST borrowck, as well, which will need to be tweaked: |
Let me play devil's advocate for minute: is the transition necessary? Why not just switch to the new borrow checker and immediately issue errors for the invalid code? Correct me if I'm wrong, but errors missed by the old borrow checker are presumably soundness issues, and my understanding is that soundness issues have been fixed ASAP in the past without concerns for backward compatibility. It would be a more abrupt approach, but would simplify things greatly, and avoid performance problems caused by running two borrow checkers. |
@nnethercote note that -- once #52083 lands -- we will only run the AST borrow checker in the case of error, which is less important to overall performance. There are still some performance wins that we can get once we rip out the old borrow check though. Regardless, it's really not an option to stop a non-trivial portion of the existing crates from compiling -- particularly since some of those new NLL errors may be bugs. |
triage: P-high |
(also, I am scheduled to discuss this with @spastorino tonight) |
visiting for triage. @spastorino and I have made progress. I hope to have a PR up this week. |
For unit testing purposes, there are a some minimized repros in the crater run reports: pieces of code accepted by AST borrowck and rejected by MIR borrowck. Some of those are definitely MIR borrowck bugs, so I'll just list some but they may need to be filtered :) Example one |
…ate, r=nikomatsakis Buffer NLL errors Buffer the errors generated during MIR-borrowck (aka NLL). This is the first big step towards resolving issue #46908.
Assigning to @pnkfelix, he took this over. Ping me if I can help in some way :). |
visited for triage. I've got a branch that is almost ready to be made into a PR; I just need to resolve one issue with the new MIR-codegen enabled by NLL causing an ICE downstream when it is given (unsound) code that was previously accepted by the AST-borrowck. |
Add `-Z borrowck=migrate` This adds `-Z borrowck=migrate`, which represents the way we want to migrate to NLL under Rust versions to come. It also hooks this new mode into `--edition 2018`, which means we're officially turning NLL on in the 2018 edition. The basic idea of `-Z borrowck=migrate` that there are cases where NLL is fixing old soundness bugs in the borrow-checker, but in order to avoid just breaking code by immediately rejecting the programs that hit those soundness bugs, we instead use the following strategy: If your code is accepted by NLL, then we accept it. If your code is rejected by both NLL and the old AST-borrowck, then we reject it. If your code is rejected by NLL but accepted by the old AST-borrowck, then we emit the new NLL errors as **warnings**. These warnings will be turned into hard errors in the future, and they say so in these diagnostics. Fix #46908
Task list:
-Z borrowck=migrate
; it first runs NLL. If the code passes, then we're done. If there were errors buffered, then before emitting its buffered errors, it runs AST-borrowck in the aforementioned pure mode. If AST-borrowck signals any error, then emit the NLL errors. If the AST-borrowck accepts the code, then downgrade all the NLL errors to warnings and then emit them.Original bug report follows:
We are currently planning on an initial deployment of non-lexical lifetimes (NLL) via an opt-in feature flag
#![feature(nll)]
(which actually just landed last night, woo hoo)!However, our plan is not to just choose some arbitrary point in the future and making
#![feature(nll)]
the default with no warning.In particular, there is some code that is accepted today under AST borrowck that NLL rejects. So we need a migration path.
Luckily, we already have the pieces in place to run both AST-borrowck and MIR-borrowck (aka NLL). So we can make that part of the migration path.
In particular, lets add a
-Z borrowck=migrate
flag. When its turned on, we run both borrow checkers (much the same way that-Z borrowck=compare
does today). But now we consider both results when reporting errors:Of course the devil is in the details here. In particular, the above breakdown acts like one can always meaningfully relate the errors generated by AST- and MIR-borrowck, but the reality is that the two will differ in their reports.
To avoid presenting duplicated sets of errors from both AST- and MIR-borrowck in the cases where they both reject, my plan is to use the error code numbers as an approximation to whether an error was signaled or not from AST-borrowck before deciding whether to report it or treat it as a warning from MIR-borrowck.
The text was updated successfully, but these errors were encountered: