Skip to content

Wrong error message when omitting braces from closure with return type which returns tuple #138748

New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Closed
schuelermine opened this issue Mar 20, 2025 · 0 comments · Fixed by #138749
Closed
Assignees
Labels
A-diagnostics Area: Messages for errors, warnings, and lints T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@schuelermine
Copy link
Contributor

Code

fn main() {
    let f: Box<dyn Fn() -> (i32, i32)> = Box::new(|| -> (i32, i32) (1, 2));
}

Current output

error: this is a block expression, not an array
 --> src/main.rs:2:68
  |
2 |     let f: Box<dyn Fn() -> (i32, i32)> = Box::new(|| -> (i32, i32) (1, 2));
  |                                                                    ^^^^^
  |
help: to make an array, use square brackets instead of curly braces
  |
2 -     let f: Box<dyn Fn() -> (i32, i32)> = Box::new(|| -> (i32, i32) (1, 2));
2 +     let f: Box<dyn Fn() -> (i32, i32)> = Box::new(|| -> (i32, i32) [1, ]));
  |

error: expected one of `.`, `;`, `?`, `else`, or an operator, found `)`
 --> src/main.rs:2:74
  |
2 |     let f: Box<dyn Fn() -> (i32, i32)> = Box::new(|| -> (i32, i32) (1, 2));
  |                                                                          ^ expected one of `.`, `;`, `?`, `else`, or an operator

Desired output

Rationale and extra context

No response

Other cases

Rust Version

rustc 1.87.0-nightly (1aeb99d24 2025-03-19)
binary: rustc
commit-hash: 1aeb99d248e1b0069110cb03c6f1dcc7b36fd7f3
commit-date: 2025-03-19
host: x86_64-unknown-linux-gnu
release: 1.87.0-nightly
LLVM version: 20.1.0

Anything else?

No response

@schuelermine schuelermine added A-diagnostics Area: Messages for errors, warnings, and lints T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Mar 20, 2025
@compiler-errors compiler-errors self-assigned this Mar 20, 2025
bors added a commit to rust-lang-ci/rust that referenced this issue Mar 31, 2025
…fmease

Fix closure recovery for missing block when return type is specified

Firstly, fix the `is_array_like_block` condition to make sure we're actually recovering a mistyped *block* rather than some other delimited expression. This fixes rust-lang#138748.

Secondly, split out the recovery of missing braces on a closure body into a separate recovery. Right now, the suggestion `"you might have meant to write this as part of a block"` originates from `suggest_fixes_misparsed_for_loop_head`, which feels kinda brittle and coincidental since AFAICT that recovery wasn't ever really intended to fix this.

We also can make this `MachineApplicable` in this case.

Fixes rust-lang#138748

r? `@fmease` or reassign if you're busy/don't wanna review this
@bors bors closed this as completed in 0a579d5 Mar 31, 2025
rust-timer added a commit to rust-lang-ci/rust that referenced this issue Mar 31, 2025
Rollup merge of rust-lang#138749 - compiler-errors:closure-recovery, r=fmease

Fix closure recovery for missing block when return type is specified

Firstly, fix the `is_array_like_block` condition to make sure we're actually recovering a mistyped *block* rather than some other delimited expression. This fixes rust-lang#138748.

Secondly, split out the recovery of missing braces on a closure body into a separate recovery. Right now, the suggestion `"you might have meant to write this as part of a block"` originates from `suggest_fixes_misparsed_for_loop_head`, which feels kinda brittle and coincidental since AFAICT that recovery wasn't ever really intended to fix this.

We also can make this `MachineApplicable` in this case.

Fixes rust-lang#138748

r? `@fmease` or reassign if you're busy/don't wanna review this
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
A-diagnostics Area: Messages for errors, warnings, and lints T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants