-
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
Assigning break to a variable hits type checking errors even outside a loop #13292
Comments
This is a bit tricky. The same error is actually sensible if there is an outer loop: fn main() { loop { let x = { break }; } } But if fn main() { let x = { break }; } |
Closing as working as intended. Loop checking occurs after typechecking (and this is caught by loop checking), and typechecking is hitting the legitimate error that it's doesn't have the type of the local variable. |
I filed this because I think that we can/should move loop checking earlier, since it gives the information about how to fix things in cases like these (a type error is useless in comparision, it's obviously 100% correct, but it doesn't pin-point the issue like the loop error does). Is there some fundamental problem with moving error checking passes as early as is reasonable? (since this is just an AST visit with no need for any other information it move whereever.) |
Ah, ok. In that case, I do believe that loop checking can move up the chain of passes, it was quite a small file. |
rustc: move the check_loop pass earlier. This pass is purely AST based, and by running it earlier we emit more useful error messages, e.g. type inference fails in the case of `let r = break;` with few constraints on `r`, but it's more useful to be told that the `break` is outside the loop (rather than a type error) when it is. Closes #13292.
check std::panic::panic_any in panic lint close rust-lang#13292 This PR detects `std::panic::panic_any` in panic lint. changelog: check std::panic::panic_any in panic lint
I would think this should just emit the same error as
The text was updated successfully, but these errors were encountered: