Skip to content
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

[unused_braces] Lint multiline blocks as long as not in arms #102432

Closed
wants to merge 2 commits into from

Conversation

kraktus
Copy link
Contributor

@kraktus kraktus commented Sep 28, 2022

The commit message include removing braces in arm matches but I could not find a way to make a suggestion for it, since it some cases you would need to replace the block by a comma
Example:

match expr {
    pat => {()}
    _ => println!("foo")
}
  • We still do not lint multiline match arms used for formatting reasons
match expr {
   pat => {
       somewhat_long_expression
   }
 // ...
}

?r @lcnr since we discussed briefly about it on zulip. Happy to have your feedback on this

@rustbot rustbot added T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Sep 28, 2022
@rust-highfive
Copy link
Collaborator

r? @Mark-Simulacrum

(rust-highfive has picked a reviewer for you, use r? to override)

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Sep 28, 2022
@rustbot
Copy link
Collaborator

rustbot commented Sep 28, 2022

Hey! It looks like you've submitted a new PR for the library teams!

If this PR contains changes to any rust-lang/rust public library APIs then please comment with @rustbot label +T-libs-api -T-libs to tag it appropriately. If this PR contains changes to any unstable APIs please edit the PR description to add a link to the relevant API Change Proposal or create one if you haven't already. If you're unsure where your change falls no worries, just leave it as is and the reviewer will take a look and make a decision to forward on if necessary.

Examples of T-libs-api changes:

  • Stabilizing library features
  • Introducing insta-stable changes such as new implementations of existing stable traits on existing stable types
  • Introducing new or changing existing unstable library APIs (excluding permanently unstable features / features without a tracking issue)
  • Changing public documentation in ways that create new stability guarantees
  • Changing observable runtime behavior of library APIs

@kraktus
Copy link
Contributor Author

kraktus commented Sep 28, 2022

r? @lcnr

@rust-log-analyzer

This comment has been minimized.

Copy link
Contributor

@lcnr lcnr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

instead of modifying the ui tests, can you add #![allow(unused_braces)] to the tests instead

apart from that these changes look good to me, not sure if changing a style lint like this warrants a more formal decision, so I am just going to get another compiler member to also sign this off 🤷

compiler/rustc_lint/src/unused.rs Outdated Show resolved Hide resolved
@lcnr
Copy link
Contributor

lcnr commented Sep 29, 2022

r? compiler

@rust-highfive rust-highfive assigned davidtwco and unassigned lcnr Sep 29, 2022
@rust-log-analyzer

This comment has been minimized.

@rustbot
Copy link
Collaborator

rustbot commented Sep 30, 2022

Some changes occurred in compiler/rustc_codegen_cranelift

cc @bjorn3

@kraktus kraktus marked this pull request as draft September 30, 2022 15:03
@kraktus
Copy link
Contributor Author

kraktus commented Sep 30, 2022

Saving the comments before rebasing

with_no_trimmed_paths!({
I think this should stay the same. The content of the block is a statement, not an expression. Same for the other changed use of with_no_trimmed_paths in cg_cl

I think you should skip changing tests. It may unintentionally change the meaning of the tests. We don't run rustfmt on tests at all.

@kraktus kraktus force-pushed the useless_braces branch 3 times, most recently from 76cc9cc to 4653e5c Compare September 30, 2022 15:56
@rust-log-analyzer

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

@calebcartwright
Copy link
Member

I just want to emphasize that the concern raised was not exclusive to match_ast! nor any other singular macro. Applying a precise workaround to the current macro at hand would indeed be a helpful step forward, but I also wonder if it would be worthwhile (or practical) to run a broader test. Not sure if crater runs can be used to flag potential issues with new lints?

@kraktus
Copy link
Contributor Author

kraktus commented Jan 13, 2023

I just want to emphasize that the concern raised was not exclusive to match_ast! nor any other singular macro. Applying a precise workaround to the current macro at hand would indeed be a helpful step forward, but I also wonder if it would be worthwhile (or practical) to run a broader test. Not sure if crater runs can be used to flag potential issues with new lints?

Afaik craters only look at compilation failures, so this lint could be sent as deny before running it and see how many crates now fail to compile.

To be accurate the number of failure should not take into account crates that would have triggered this lint before its scope expansion.

@kraktus kraktus force-pushed the useless_braces branch 5 times, most recently from f79f70c to 0e5a741 Compare January 13, 2023 23:59
@kraktus
Copy link
Contributor Author

kraktus commented Jan 14, 2023

Solution 2. (silencing the warning on match_ast!) has been applied and tests are passing. Waiting for more input on the possible crater run.

@bors
Copy link
Contributor

bors commented Jan 16, 2023

☔ The latest upstream changes (presumably #106914) made this pull request unmergeable. Please resolve the merge conflicts.

@kraktus kraktus force-pushed the useless_braces branch 2 times, most recently from e5d339c to 9f203f2 Compare January 16, 2023 13:16
@bors
Copy link
Contributor

bors commented Jan 26, 2023

☔ The latest upstream changes (presumably #105582) made this pull request unmergeable. Please resolve the merge conflicts.

Currently the lint faces a severe limitation: since it only catches single-line block, running rustfmt beforehand will remove all occurences of it, because it breaks them into multiline blocks.

We do not check match `Arm` for two reasons:
- In case it does not use commas to separate arms, removing the block would result in a compilation error
Example:
```
    match expr {
        pat => {()}
        _ => println!("foo")
    }
    ```
    - Do not lint multiline match arms used for formatting reasons
    ```
    match expr {
       pat => {
           somewhat_long_expression
       }
     // ...
    }
```

Delete `unused-braces-lint` test

The modified lint correctly provide a span in its suggestion.

```shell
    error: unnecessary braces around block return value
      --> /rust/src/test/rustdoc-ui/unused-braces-lint.rs:9:5
       |
    LL | /     {
    LL | |         {
       | |________^
    LL |               use std;
    LL |           }
       |  __________^
    LL | |     }
       | |_____^
       |
    note: the lint level is defined here
      --> /rust/src/test/rustdoc-ui/unused-braces-lint.rs:6:9
       |
    LL | #![deny(unused_braces)]
       |         ^^^^^^^^^^^^^
    help: remove these braces
       |
    LL ~     {
    LL |             use std;
    LL ~         }
       |
```

It is unclear to which extend rust-lang#70814 is still an issue, as the inital MCVE does not trigger the lint on stable either,[rust playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=b6ff31a449c0b73a08daac8ee43b1fa6)

Fix code with expanded `unused_braces` lint

Also allow `unused_braces` on tests

Mute `unused_braces` on `match_ast!`
@kraktus
Copy link
Contributor Author

kraktus commented Feb 1, 2023

Solution 2. (silencing the warning on match_ast!) has been applied and tests are passing. Waiting for more input on the possible crater run.

@calebcartwright gentle ping about this

@bors
Copy link
Contributor

bors commented Feb 16, 2023

☔ The latest upstream changes (presumably #101841) made this pull request unmergeable. Please resolve the merge conflicts.

@compiler-errors compiler-errors self-assigned this Feb 22, 2023
@davidtwco davidtwco removed their assignment Feb 23, 2023
@compiler-errors
Copy link
Member

compiler-errors commented Feb 23, 2023

T-style discussed this yesterday in our meeting.

Our recommendation is that this change should not be enforced within macro args. Is it possible to modify your implementation to continue silently accepting those cases? It should be possible with the visitor structure of the lint.

Also, I would be keen on reverting the usages of with_no_trimmed_paths!({ .. }), etc. from a compiler reviewer perspective.

@compiler-errors
Copy link
Member

@rustbot author

Waiting on changes to be made + a rebase, use @rustbot author to mark it ready for review :)

@rustbot rustbot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Mar 1, 2023
@lnicola
Copy link
Member

lnicola commented Mar 3, 2023

Our recommendation is that this change should not be enforced within macro args.

Given this, do we still need the RA change?

@kraktus
Copy link
Contributor Author

kraktus commented Mar 3, 2023

It shouldn't be necessary anymore

@JohnCSimon
Copy link
Member

JohnCSimon commented May 28, 2023

@kraktus
ping from triage - can you post your status on this PR? There hasn't been an update in a few months. Thanks!

FYI: when a PR is ready for review, send a message containing
@rustbot ready to switch to S-waiting-on-review so the PR is in the reviewer's backlog.

@lnicola
Copy link
Member

lnicola commented May 28, 2023

It shouldn't be necessary anymore

FWIW it's still there 🙂.

@kraktus
Copy link
Contributor Author

kraktus commented May 28, 2023

Hey, thanks for the ping, I don’t plan to work on this PR in the foreseeable future.

@compiler-errors
Copy link
Member

In that case, closing this PR. Thanks for the contribution.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue. T-style Relevant to the style team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet