unnecessary parentheses around type in attribute macro

[lesurp]

Code

Since this is related to proc_macro reproducing is slightly troublesome. The original problem originated here: https://github.com/lesurp/OptionalStruct/blob/master/tests/nested.rs

Simplified call site:

struct Foo;
struct Baz;

#[optional_struct]
struct Bar {
    #[optional_rename(Foo)]
    log_config: Baz,
}

Note that the macro is not a derive macro (and the attribute optional_rename not a derive macro helper attributes).

Current output

warning: unnecessary parentheses around type
 --> tests/reverse_wrapping.rs:7:22
  |
7 |     #[optional_rename(Foo)]
  |                      ^                 ^
  |
  = note: `#[warn(unused_parens)]` on by default
help: remove these parentheses
  |
7 -     #[optional_rename(Foo)]
7 +     #[optional_renameFoo]
  |

Desired output

No warning.

Rationale and extra context

The parentheses are read as part of the type, but they are part of the attribute definition.

Other cases

No response

Anything else?

No response

[clubby789]

The problem is that the tokens include the parentheses. You can use parse_args to parse the argument as a proc_macro2::Ident which does not include the parentheses.

[lesurp]

Hi, thank you very much this indeed solved the problem. I did not even realize the warning came from the parentheses actually being unused, I thought that warning was emitted even before my macro was expanded.

I'm wondering if there would be any way to improve the diagnostic here?

[estebank]

Sadly we somewhat rely on proc macros being well-formed, but we should make more of an effort helping proc-macro authors debug their own code.

[Antikyth]

Sadly we somewhat rely on proc macros being well-formed, but we should make more of an effort helping proc-macro authors debug their own code.

I've encountered similar when writing my (perhaps overly complex and overly ambition) proc macro - at a certain level of complexity, a lot of these errors for me originate either from:
(a) confusion as to what spans should be applied to what areas of the expanded code; and
(b) a general inability to annotate certain areas of expanded code as ignoring particular lints, while still allowing others to be linted as norm.

By (b), I mean that there are certain things, like applying a 'template' of expanded code to the user-provided syntax, that are likely to violate a number of lints (e.g. like in this issue, or more commonly things like unnecessary borrows which are sometimes necessary, depending on the types used in the syntax by the user), where you want to allow those lints on that expanded code, but then within those there might be syntax which you do want to be linted, because it was defined by the user (or mostly defined).

I realize this is not the place to discuss these errors, it's just what immediately came to mind when seeing the issue. I'm not sure where the correct place to discuss them would be if I were to do that.

[estebank]

I'm not sure where the correct place to discuss them would be if I were to do that.

https://internals.rust-lang.org/ and https://rust-lang.zulipchat.com/#narrow/stream/147480-t-compiler.2Fwg-diagnostics