-
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
ICE: polonius loan scopes differ from NLL borrow scopes
#125992
Comments
failed: polonius loan scopes differ from NLL borrow scopes
polonius loan scopes differ from NLL borrow scopes
Amanda (and I, when I have a bit more time) will also look into this soon-ish to try and see where NLLs differ from the location-insensitive pass in this new situation. |
I can narrow that down to specifically: outlives_constraints = Default::default(); Looking into a work-around! |
The problem is that NLL has an optimisation for computing loans out of scope that shortens the scope to skip the two final reborrows in the generated MIR body because |
This only happens when the "remove constraints" trick of @oli-obk's is engaged because liveness values are merged into SCCs during construction of Ironically this means that NLL is now slightly context-sensitive in the sense that parts of the constraint graph disappears between MIR statements. |
I don't think I can safely convert the work-around to Polonius since I'd have to either move the liveness logic to a later stage of computation (design change) or undo parts of the computation of the |
Avoid follow-up errors and ICEs after missing lifetime errors on data structures Tuple struct constructors are functions, so when we call them typeck will use the signature tuple struct constructor function to provide type hints. Since typeck mostly ignores and erases lifetimes, we end up never seeing the error lifetime in writeback, thus not tainting the typeck result. Now, we eagerly taint typeck results by tainting from `resolve_vars_if_possible`, which is called all over the place. I did not carry over all the `crashes` test suite tests, as they are really all the same cause (missing or unknown lifetime names in tuple struct definitions or generic arg lists). fixes rust-lang#124262 fixes rust-lang#124083 fixes rust-lang#125155 fixes rust-lang#125888 fixes rust-lang#125992 fixes rust-lang#126666 fixes rust-lang#126648 fixes rust-lang#127268
…ler-errors Avoid follow-up errors and ICEs after missing lifetime errors on data structures Tuple struct constructors are functions, so when we call them typeck will use the signature tuple struct constructor function to provide type hints. Since typeck mostly ignores and erases lifetimes, we end up never seeing the error lifetime in writeback, thus not tainting the typeck result. Now, we eagerly taint typeck results by tainting from `resolve_vars_if_possible`, which is called all over the place. I did not carry over all the `crashes` test suite tests, as they are really all the same cause (missing or unknown lifetime names in tuple struct definitions or generic arg lists). fixes rust-lang#124262 fixes rust-lang#124083 fixes rust-lang#125155 fixes rust-lang#125888 fixes rust-lang#125992 fixes rust-lang#126666 fixes rust-lang#126648 fixes rust-lang#127268
auto-reduced (treereduce-rust):
original:
Version information
Command:
/home/matthias/.rustup/toolchains/master/bin/rustc -Zpolonius=next
Program output
@rustbot label +F-inherent_associated_types
The text was updated successfully, but these errors were encountered: