Fix collapsible_match suggesting wrong span when arm block has a label#17437
Fix collapsible_match suggesting wrong span when arm block has a label#17437Halloloid wants to merge 2 commits into
Conversation
rustbot
added
the
S-waiting-on-community-reviews
|
Thanks for the pull request, and welcome! You should hear from one of our reviewers after this PR gets at least 2 reviews from the community. 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 (
|
rustbot
added
the
S-waiting-on-review
|
@rustbot review |
Updated — now skips the suggestion entirely if no opening brace is found, instead of falling back to position 0. |
| let block_snippet = snippet(cx, block_span, ""); | ||
| let Some(brace_offset) = block_snippet.find('{') else { | ||
| return; | ||
| }; |
There was a problem hiding this comment.
What if I do something like this:
'label: /* { .... } */ {I believe the current solution would confuse both since the comment would be included block_snippet.
4 participants
Fixes #17427
collapsible_matchwas computing the wrong span for the opening braceof a match arm's block when that block had a label (e.g.
'label: { ... }).It assumed the first byte of the block's span was always
{, which onlyholds when there's no label — with a label present, the suggestion ended
up deleting the leading
'of the label instead of the arrow, producingcode that failed to compile ("unclosed delimiter").
This finds the actual
{position instead of assuming it's the first byte,and re-inserts the label text after the
=>in the suggestion so it isn'tsilently dropped.
Added a regression test (
issue17427intests/ui/collapsible_match_fixable.rs)covering the labeled-block case, verified via both
.stderrand.fixed(rustfix-applied output actually compiles).
changelog: [
collapsible_match]: fix incorrect suggestion span causing acompile error when the outer match arm's block has a label