-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
Incorrect parser error when match statement is missing its ; #40799
Comments
I don't see a parser error. I see a type error as I expected. For posterity: the code is fn main() {
match 3 {
4 => 1,
3 => {
println!("Yep it maches.");
2
}
_ => 2
}
println!("Bye!")
} And the error is
|
I dissagree. The pragmatic reason I dissagree, is that the error is useless. It fails to identify the location and the kind of mistake that the programmer has made. The pendantic reason I dissagree, is that the error is wrong.
The match arms do NOT have incompatible types. Every arm of the match evaluates, eventually, to an A correct type error would be:
|
The initial error message is correct:
Everything else continues from there. Probably just a case of passing up a real type (the tuple) instead of |
This comment has been minimized.
This comment has been minimized.
…atthewjasper Account for tail expressions when pointing at return type When there's a type mismatch we make an effort to check if it was caused by a function's return type. This logic now makes sure to only point at the return type if the error happens in a tail expression. Turn `walk_parent_nodes` method into an iterator. CC rust-lang#39968, CC rust-lang#40799.
…atthewjasper Account for tail expressions when pointing at return type When there's a type mismatch we make an effort to check if it was caused by a function's return type. This logic now makes sure to only point at the return type if the error happens in a tail expression. Turn `walk_parent_nodes` method into an iterator. CC rust-lang#39968, CC rust-lang#40799.
…atthewjasper Account for tail expressions when pointing at return type When there's a type mismatch we make an effort to check if it was caused by a function's return type. This logic now makes sure to only point at the return type if the error happens in a tail expression. Turn `walk_parent_nodes` method into an iterator. CC rust-lang#39968, CC rust-lang#40799.
Point at enclosing match when expecting `()` in arm When encountering code like the following: ```rust fn main() { match 3 { 4 => 1, 3 => { println!("Yep it maches."); 2 } _ => 2 } println!("Bye!") } ``` point at the enclosing `match` expression and suggest ignoring the returned value: ``` error[E0308]: mismatched types --> $DIR/match-needing-semi.rs:8:13 | LL | / match 3 { LL | | 4 => 1, LL | | 3 => { LL | | 2 | | ^ expected (), found integer LL | | } LL | | _ => 2 LL | | } | | -- help: consider using a semicolon here | |_____| | expected this to be `()` | = note: expected type `()` found type `{integer} ``` Fix rust-lang#40799.
Point at enclosing match when expecting `()` in arm When encountering code like the following: ```rust fn main() { match 3 { 4 => 1, 3 => { println!("Yep it maches."); 2 } _ => 2 } println!("Bye!") } ``` point at the enclosing `match` expression and suggest ignoring the returned value: ``` error[E0308]: mismatched types --> $DIR/match-needing-semi.rs:8:13 | LL | / match 3 { LL | | 4 => 1, LL | | 3 => { LL | | 2 | | ^ expected (), found integer LL | | } LL | | _ => 2 LL | | } | | -- help: consider using a semicolon here | |_____| | expected this to be `()` | = note: expected type `()` found type `{integer} ``` Fix rust-lang#40799.
I found an analog of bug #40006 (Forty thousand bugs, you've gotta be kidding me! :D You've put in a lot of work there!) and @sanxiyn asked me to file my own report, so here it is.
If you don't put a ; at the end of a match block then the compiler tells you very unrelated things: https://play.rust-lang.org/?gist=ab74d4c0f3dce8c095f79469bc69b072&version=nightly&backtrace=0
The text was updated successfully, but these errors were encountered: