-
Notifications
You must be signed in to change notification settings - Fork 13.3k
MIR-borrowck: ICE: broken MIR moving out of Lvalue #44830
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
Comments
Transcription of relevant tests according to the discrepancy spreadsheet. (caveat: data is based on out-of-date pnkfelix/mir-borrowck4 branch)
|
I'm going to focus on this bug. |
This shouldn't be so hard. You'll need to remove the ICE and replace it with proper permission checking that emits the correct errors. |
Yeah, the biggest part is probably just the refactoring of the existing errors being collected and emitted within AST borrowck, and moving those to the common diagnostics that live in |
(my basic goal at this point is to remove all of the ICE's first so that we can then focus on the more interesting places where mir-borrowck is actually producing wrong answers.) |
…rrors, r=nikomatsakis MIR-borrowck: gather and signal any move errors When building up the `MoveData` structure for a given MIR, also accumulate any erroneous actions, and then report all of those errors when the construction is complete. This PR adds a host of move-related error constructor methods to `trait BorrowckErrors`. I think I got the notes right; but we should plan to audit all of the notes before turning MIR-borrowck on by default. Fix #44830
There are many tests in
compile-fail/borrowck/
that ICE with the same failure: "broken MIR moving out of Lvalue"pnkfelix believes the origin of this problem is that some code processing MIR (probably MIR dataflow) was written under the assumption that all valid MIR will not have moves out of Lvalues, at least for non-
Copy
values. But of course such an assumption only holds for MIR that has actually passed the borrowck analysis (at least under our current separation of concerns in the static analyses ofrustc
), and therefore any dataflow code running prior to borrowck on some (erroneous) Rust source file is going to potentially encounter such MIR.librustc_mir/dataflow/move_paths/builder.rs
that is the culprit here.The answer here is not to panic from
rustc
, but instead to fail gracefully in some manner and report a nice error diagnostic to the user.The text was updated successfully, but these errors were encountered: