Skip to content

If a label is placed on the block of a loop instead of the header, suggest moving it to the header. #138589

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

Merged

Conversation

zachs18
Copy link
Contributor

@zachs18 zachs18 commented Mar 17, 2025

Fixes #138585

If a label is placed on the block of a loop instead of the header, suggest to the user moving it to the loop header instead of suggesting to remove it emitting a tool-only suggestion to remove it.

fn main() {
    loop 'a: { return; }
}
 error: block label not supported here
  --> src/main.rs:2:10
   |
 2 |     loop 'a: { return; }
   |          ^^^ not supported here
+  |
+help: if you meant to label the loop, move this label before the loop
+  |
+2 -     loop 'a: { return; }
+2 +     'a: loop { return; }
+  |

Questions for reviewer:

  • The "desired output" in the linked issue had the main diagnostic be "misplaced loop label". Should the main diagnostic message the changed instead of leaving it as "block label not supported here"?
  • Should this be Applicability::MachineApplicable?

@rustbot
Copy link
Collaborator

rustbot commented Mar 17, 2025

r? @petrochenkov

rustbot has assigned @petrochenkov.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Mar 17, 2025
@zachs18
Copy link
Contributor Author

zachs18 commented Mar 17, 2025

@rustbot label +A-diagnostics

@rustbot rustbot added the A-diagnostics Area: Messages for errors, warnings, and lints label Mar 17, 2025
@petrochenkov
Copy link
Contributor

@bors r+

@bors
Copy link
Collaborator

bors commented Mar 18, 2025

📌 Commit f478853 has been approved by petrochenkov

It is now in the queue for this repository.

@bors
Copy link
Collaborator

bors commented Mar 18, 2025

🌲 The tree is currently closed for pull requests below priority 100. This pull request will be tested once the tree is reopened.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Mar 18, 2025
@petrochenkov
Copy link
Contributor

Questions for reviewer:

The implemented behavior looks fine to me.

bors added a commit to rust-lang-ci/rust that referenced this pull request Mar 19, 2025
…iaskrgr

Rollup of 7 pull requests

Successful merges:

 - rust-lang#135394 (`MaybeUninit` inherent slice methods part 2)
 - rust-lang#137051 (Implement default methods for `io::Empty` and `io::Sink`)
 - rust-lang#138001 (mir_build: consider privacy when checking for irrefutable patterns)
 - rust-lang#138540 (core/slice: Mark some `split_off` variants unstably const)
 - rust-lang#138589 (If a label is placed on the block of a loop instead of the header, suggest moving it to the header.)
 - rust-lang#138594 (Fix next solver handling of shallow trait impl check)
 - rust-lang#138613 (Remove E0773 "A builtin-macro was defined more than once.")

Failed merges:

 - rust-lang#138602 (Slim `rustc_parse_format` dependencies down)

r? `@ghost`
`@rustbot` modify labels: rollup
bors added a commit to rust-lang-ci/rust that referenced this pull request Mar 19, 2025
…iaskrgr

Rollup of 7 pull requests

Successful merges:

 - rust-lang#135394 (`MaybeUninit` inherent slice methods part 2)
 - rust-lang#137051 (Implement default methods for `io::Empty` and `io::Sink`)
 - rust-lang#138001 (mir_build: consider privacy when checking for irrefutable patterns)
 - rust-lang#138540 (core/slice: Mark some `split_off` variants unstably const)
 - rust-lang#138589 (If a label is placed on the block of a loop instead of the header, suggest moving it to the header.)
 - rust-lang#138594 (Fix next solver handling of shallow trait impl check)
 - rust-lang#138613 (Remove E0773 "A builtin-macro was defined more than once.")

Failed merges:

 - rust-lang#138602 (Slim `rustc_parse_format` dependencies down)

r? `@ghost`
`@rustbot` modify labels: rollup
@bors bors merged commit c3f74bc into rust-lang:master Mar 20, 2025
6 checks passed
@rustbot rustbot added this to the 1.87.0 milestone Mar 20, 2025
rust-timer added a commit to rust-lang-ci/rust that referenced this pull request Mar 20, 2025
Rollup merge of rust-lang#138589 - zachs18:block-label-not-supported-here-loop-body-help, r=petrochenkov

If a label is placed on the block of a loop instead of the header, suggest moving it to the header.

Fixes rust-lang#138585

If a label is placed on the block of a loop instead of the header, suggest to the user moving it to the loop header instead of ~~suggesting to remove it~~ emitting a tool-only suggestion to remove it.

```rs
fn main() {
    loop 'a: { return; }
}
```

```diff
 error: block label not supported here
  --> src/main.rs:2:10
   |
 2 |     loop 'a: { return; }
   |          ^^^ not supported here
+  |
+help: if you meant to label the loop, move this label before the loop
+  |
+2 -     loop 'a: { return; }
+2 +     'a: loop { return; }
+  |
```

Questions for reviewer:

* The "desired output" in the linked issue had the main diagnostic be "misplaced loop label". Should the main diagnostic message the changed instead of leaving it as "block label not supported here"?
* Should this be `Applicability::MachineApplicable`?
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-diagnostics Area: Messages for errors, warnings, and lints S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

"block label not supported here" when the label is in the wrong place
4 participants