You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Missing trailing expression in block with let else yields incorrectly spanned error message #94176
#![feature(let_else)]pubfntest(a:Option<u32>) -> Option<u32>{letSome(_) = a else{returnNone;};println!("Foo");}fnmain(){}
I expected to see this happen: A helpful error message pointing to the end of the block.
Instead, this happened: An error message with a wrong span:
error[E0308]: mismatched types
--> test.rs:4:5
|
4 | let Some(_) = a else{returnNone;};
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected enum `Option`, found `()`
|
= note: expected enum `Option<u32>`
found unit type `()`
error: aborting due to previous error
For more information about this error, try `rustc --explain E0308`.
pubfntest(a:Option<u32>) -> Option<u32>{ifletSome(_) = a {}else{returnNone;}println!("Foo");}
error[E0308]: mismatched types
--> src/main.rs:3:32
|
3 | pub fn test(a: Option<u32>) -> Option<u32> {
| ---- ^^^^^^^^^^^ expected enum `Option`, found `()`
| |
| implicitly returns `()` as its body has no tail or `return` expression
|
= note: expected enum `Option<u32>`
found unit type `()`
I wonder how #94012 is affecting this, as this seems to be a bug in the desugaring and that PR changes it. @cormacrelf what is the error output with your PR applied? Does it fix the issue? If so, maybe adding a test to your PR would be helpful.
It won't fix it. This needs a bit of work I think, to push the error further inside the if-let-else branch, so the span marked is the implicit return expression or lack thereof, which is (in the source code) further down in the block.
I'm starting to think the nested desugaring is not such a good idea. Even the guy who implemented it forgot how it worked the other day, it continues to mystify, and now we have some more error message complications. It's less work in hir lowering, but has absolutely no other benefits.
Activity
JakobDegen commentedon Feb 20, 2022
Let's try that again...
@rustbot label +T-compiler +F-let-else +requires-nightly +A-diagnostics
est31 commentedon Feb 20, 2022
FTR this is the error for the
if letequivalent:est31 commentedon Feb 20, 2022
I wonder how #94012 is affecting this, as this seems to be a bug in the desugaring and that PR changes it. @cormacrelf what is the error output with your PR applied? Does it fix the issue? If so, maybe adding a test to your PR would be helpful.
est31 commentedon Feb 20, 2022
I meant caused by the desugaring, not in the desugaring.
cormacrelf commentedon Feb 20, 2022
It won't fix it. This needs a bit of work I think, to push the error further inside the if-let-else branch, so the span marked is the implicit return expression or lack thereof, which is (in the source code) further down in the block.
est31 commentedon Feb 20, 2022
Hmm if you move the println into the
if let, it gives a similar error to the one emitted bylet else:gives
cormacrelf commentedon Feb 21, 2022
That's because you have only now reproduced the actual desugaring.
cormacrelf commentedon Feb 21, 2022
I'm starting to think the nested desugaring is not such a good idea. Even the guy who implemented it forgot how it worked the other day, it continues to mystify, and now we have some more error message complications. It's less work in hir lowering, but has absolutely no other benefits.Rollup merge of rust-lang#100443 - est31:let_else_regression_tests, r…
Rollup merge of rust-lang#93628 - est31:stabilize_let_else, r=joshtri…
Rollup merge of rust-lang#93628 - est31:stabilize_let_else, r=joshtri…