Catch stray { in let-chains

[sjwang05]

Fixes #117766

[rustbot]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @TaKO8Ki (or someone else) soon.

Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (S-waiting-on-review and S-waiting-on-author) stays updated, invoking these commands when appropriate:

• @rustbot author: the review is finished, PR author should check the comments and take action accordingly
• @rustbot review: the author is ready for a review, this PR will be queued again in the reviewer's queue

[estebank]

Let's move this logic to a separate method to make it less difficult to read the happy path. Either the new logic or the whole parser loop.

[estebank]

Suggested change

	err.span_note(
	err.span_label(

[estebank]

The approach is quite smart! Thank you for taking this on.

[estebank]

I'm trying to decide if it's better in general to silence this error (like we do for diff markers) or not is best for these cases... I would leave it as is for now, because I don't know if I can come up with a case where doing so would be detrimental, but suspect we can silence it.

[sjwang05]

Thanks for the feedback! I've moved all error handling logic into its separate method and replaced the note with a label as suggested.

I'm trying to decide if it's better in general to silence this error (like we do for diff markers) or not is best for these cases

I just tried doing that, and strangely enough, all "found a { in the middle of a let-chain" errors except the first get silenced as well:

error: found a `{` in the middle of a let-chain
  --> $DIR/brace-in-let-chain.rs:6:24
   |
LL |         && let () = () {
   |                        ^
LL |         && let () = ()
   |         ------ you might have meant to continue the let-chain here
   |
help: consider removing this brace to parse the `let` as part of the same chain
   |
LL -         && let () = () {
LL +         && let () = ()
   |

error: aborting due to previous error

We should be getting 2 errors here, but we're only getting one 😕.

FWIW, here's what the silenced stderr would probably look like if I manage to get that problem sorted out:

error: found a `{` in the middle of a let-chain
  --> $DIR/brace-in-let-chain.rs:14:24
   |
LL |         && let () = () {
   |                        ^
LL |         && let () = ()
   |         ------ you might have meant to continue the let-chain here
   |
help: consider removing this brace to parse the `let` as part of the same chain
   |
LL -         && let () = () {
LL +         && let () = ()
   |

error: found a `{` in the middle of a let-chain
  --> $DIR/brace-in-let-chain.rs:6:24
   |
LL |         && let () = () {
   |                        ^
LL |         && let () = ()
   |         ------ you might have meant to continue the let-chain here
   |
help: consider removing this brace to parse the `let` as part of the same chain
   |
LL -         && let () = () {
LL +         && let () = ()
   |

error: aborting due to 2 previous errors

Though I feel like it's definitely easier to read, the unclosed delimiter errors aren't necessarily wrong like they could be with diff markers, so silencing them might not be as helpful. The ideal solution is probably something like the stderr you suggested in the original issue, where the label is printed inline with the unclosed delim error, though I have no clue how I'd go about doing that--the only way I can think of is modifying the errors in report_suspicious_mismatch_block, which would require somehow pairing up each erroneous let-chain with the correct {.

[TaKO8Ki]

Thank you for the great work! I left one suggestion.

[estebank]

@bors r=estebank,TaKO8Ki

[bors]

📌 Commit 274824b has been approved by estebank,TaKO8Ki

It is now in the queue for this repository.

[bors]

⌛ Testing commit 274824b with merge ea1e5cc...

[bors]

☀️ Test successful - checks-actions
Approved by: estebank,TaKO8Ki
Pushing ea1e5cc to master...

[rust-timer]

Finished benchmarking commit (ea1e5cc): comparison URL.

Overall result: ✅ improvements - no action needed

@rustbot label: -perf-regression

Instruction count

This is a highly reliable metric that was used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-0.6%	[-0.8%, -0.3%]	2
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-0.6%	[-0.8%, -0.3%]	2

Max RSS (memory usage)

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	3.8%	[3.8%, 3.8%]	1
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-0.4%	[-0.4%, -0.4%]	1
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	1.7%	[-0.4%, 3.8%]	2

Cycles

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	0.8%	[0.6%, 0.9%]	2
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-0.7%	[-0.7%, -0.7%]	1
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	0.3%	[-0.7%, 0.9%]	3

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 673.749s -> 674.078s (0.05%)
Artifact size: 311.08 MiB -> 311.07 MiB (-0.00%)