Avoid unused braces lint for macro generated arguments#158791
Avoid unused braces lint for macro generated arguments#158791chenyukang wants to merge 1 commit into
Conversation
|
r? @folkertdev rustbot has assigned @folkertdev. Use Why was this reviewer chosen?The reviewer was selected based on:
|
| for arg in args_to_check { | ||
| if callee_from_expansion && Self::block_wraps_expanded_expr(arg) { | ||
| continue; | ||
| } |
There was a problem hiding this comment.
this deserves a comment
There was a problem hiding this comment.
Maybe
Whether an expression is wrapped in a block can change what arm of a
macro_rules!is taken. Don't report the braces as unused that might be the case.
| ); | ||
| } | ||
|
|
||
| fn block_wraps_expanded_expr(value: &ast::Expr) -> bool { |
There was a problem hiding this comment.
probably could use a comment too
| @@ -0,0 +1,38 @@ | |||
| //@ check-pass | |||
| //@ run-rustfix | |||
|
|
|||
There was a problem hiding this comment.
these days we often like to put a one-sentence description of what this is testing and why at the top of these files
27f37a2 to
b50b5b2
Compare
|
Lovely, thanks! @bors r+ rollup |
…d-braces-macro, r=folkertdev Avoid unused braces lint for macro generated arguments Fixes rust-lang#158747 This changes the `unused_braces` lint to avoid suggesting brace removal for macro arguments when those braces may affect `macro_rules!`. But the fragment kind matters: - `$e:expr` matches an expression. Both `1` and `{ 1 }` are expressions, so removing braces can still leave the macro matching the same kind of input. - `$b:block` only matches a block expression written with braces. `{ 1 }` matches, but `1` does not. So `call_expr!({ 1 })` can usually be simplified to `call_expr!(1)`, while `call_block!({ 1 })` cannot. It seems a more concrect report need a full `macro_rules!` matcher analysis, that seems too heavy for `unused` lint.
…d-braces-macro, r=folkertdev Avoid unused braces lint for macro generated arguments Fixes rust-lang#158747 This changes the `unused_braces` lint to avoid suggesting brace removal for macro arguments when those braces may affect `macro_rules!`. But the fragment kind matters: - `$e:expr` matches an expression. Both `1` and `{ 1 }` are expressions, so removing braces can still leave the macro matching the same kind of input. - `$b:block` only matches a block expression written with braces. `{ 1 }` matches, but `1` does not. So `call_expr!({ 1 })` can usually be simplified to `call_expr!(1)`, while `call_block!({ 1 })` cannot. It seems a more concrect report need a full `macro_rules!` matcher analysis, that seems too heavy for `unused` lint.
Fixes #158747
This changes the
unused_braceslint to avoid suggesting brace removal for macro arguments when those braces may affectmacro_rules!.But the fragment kind matters:
$e:exprmatches an expression. Both1and{ 1 }are expressions, so removing braces can still leave the macro matching the same kind of input.$b:blockonly matches a block expression written with braces.{ 1 }matches, but1does not.So
call_expr!({ 1 })can usually be simplified tocall_expr!(1), whilecall_block!({ 1 })cannot.It seems a more concrect report need a full
macro_rules!matcher analysis, that seems too heavy forunusedlint.