Skip to content
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

Closed
huonw opened this issue Apr 3, 2014 · 4 comments · Fixed by #13330
Closed

Assigning break to a variable hits type checking errors even outside a loop #13292

huonw opened this issue Apr 3, 2014 · 4 comments · Fixed by #13330
Labels
E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.

Comments

@huonw
Copy link
Member

huonw commented Apr 3, 2014

fn main() { let x = { break }; }
error: cannot determine a type for this local variable: unconstrained type
fn main() { let x = { break }; }
                ^~~~~~~~~~~~~

I would think this should just emit the same error as

fn main() { break }
error: `break` outside of loop
@edwardw
Copy link
Contributor

edwardw commented Apr 4, 2014

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 rustc is to report error eagerly, it is quite the same as:

fn main() { let x = { break }; }

@alexcrichton
Copy link
Member

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.

@huonw
Copy link
Member Author

huonw commented Apr 4, 2014

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.)

@huonw huonw reopened this Apr 4, 2014
@alexcrichton
Copy link
Member

Ah, ok. In that case, I do believe that loop checking can move up the chain of passes, it was quite a small file.

bors added a commit that referenced this issue Apr 5, 2014
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.
@huonw huonw closed this as completed in 3766453 Apr 5, 2014
flip1995 pushed a commit to flip1995/rust that referenced this issue Sep 5, 2024
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants