Warn when a #[test]-like built-in attribute macro is present multiple times.

[Ethiraric]

Fixes #90979.

[GuillaumeGomez]

r? @petrochenkov

[Milo123459]

Shouldn't this emit an error, not a warning? I'm trying to think of a use case where having multiple #[test]'s is a good idea and would probably make sense for it to be an error. Just giving my opinion though, it might make sense to have it as a warning.

[Ethiraric]

It could very well be an error. I don't see any case either where this would be the expected behavior. Having a hard error on that is maybe too inconvenient on what was probably an oversight from the developer and could break existing codebases.

[Milo123459]

It could very well be an error. I don't see any case either where this would be the expected behavior. Having a hard error on that is maybe too inconvenient on what was probably an oversight from the developer and could break existing codebases.

Implementing a fix for it would be super easy; it just has to remove the other usages of #[test] on that function.

[Ethiraric]

How does that weigh in whether this should be an error or a warning?

[GuillaumeGomez]

It's up to @rust-lang/compiler team I guess. But in any case, I think we have to first start with a warning saying it'll become a hard error in the future if we decide that it's not supposed to compile.

[Milo123459]

How does that weigh in whether this should be an error or a warning?

Read it wrong. My bad.

I agree - throwing a hard error might be inconsistent.

[lcnr]

we currently allow the following without any warnings as well

#[inline]
#[inline]
fn foo() {}

I think that ideally we should hard error for duplicate builtin attributes though starting with a future incompat lint is probably the right choice 🤔 imo we should start a crater run for this, you would have to first convert the warning to an error in that case.

[nagisa]

Right now the story around duplicate attributes is definitely somewhat erratic. There are some attributes which when duplicated will implement their function twice and sometimes cause an error (though outside of the attribute system). derive and test are an example of this. Some others will behave as if the attribute was specified once (e.g. #[no_mangle]), and some, such as inline will have an overriding behaviour (where only the last applies).

To be fair, I'm not sure if test having the “repeated operation” is the right model for #[test] in the first place – I would've expected it to work more like no_mangle, in which case warning would not be necessary either.

There are also considerations with regards to e.g. macros, where ability to duplicate some attributes may make things significantly easier for them.

[GuillaumeGomez]

There are also considerations with regards to e.g. macros, where ability to duplicate some attributes may make things significantly easier for them.

This is mostly why I think a warning should be enough.

[Ethiraric]

you would have to first convert the warning to an error in that case.

As implemented in this PR, the diagnostic is reported as a warning.

Should you decide on what the behavior for repeated builtin attributes should be, I am willing, in other PRs, to change their behaviors according to what you think is best.

In any case, let me know what changes you want me to do in this PR.

[ehuss]

we currently allow the following without any warnings as well

Duplicate attributes should now warn on the latest nightly.

[Ethiraric]

Duplicate attributes should now warn on the latest nightly.

It doesn't as of :

rustc 1.58.0-nightly (65c55bf93 2021-11-23)
binary: rustc
commit-hash: 65c55bf931a55e6b1e5ed14ad8623814a7386424
commit-date: 2021-11-23
host: x86_64-unknown-linux-gnu
release: 1.58.0-nightly
LLVM version: 13.0.0

[ehuss]

@Ethiraric Can you say more about what you tried? It should display a warning like this:

warning: unused attribute
 --> src/lib.rs:2:1
  |
2 | #[inline]
  | ^^^^^^^^^ help: remove this attribute
  |
  = note: `#[warn(unused_attributes)]` on by default
note: attribute also specified here
 --> src/lib.rs:1:1
  |
1 | #[inline]
  | ^^^^^^^^^
  = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!

If you tried with #[test], then that is because the lint intentionally doesn't fire on proc-macros.

[Ethiraric]

I tried to compile the file I linked on the issue with the compiler I posted the version of.

Can you try to compile the snippet from #90979 and tell me whether you have a warning?

EDIT: Sorry, hadn't noticed the last line after the snippet.
Why is that that #[test] doesn't show any diagnostic?

[ehuss]

Why is that that #[test] doesn't show any diagnostic?

#[test] is treated like a proc-macro, and not a built-in attribute. The lint only fires for built-in attributes.

[Ethiraric]

But, with the current behaviour, I don't see any case annotating an item more than once with #[test] would be desired. This is why I thought a warn (not a hard error) would be nice.

I get that because it's a particular macro there currently is no warn. I have implemented this diagnostic here because I think there should be at least something that warns user.

Do you think this would be a bad addition?

[GuillaumeGomez]

I think the same as @Ethiraric in here: having a test run as many times as the #[test] attribute is present deserves at least a warning so at least you know why it's happening (even more if it comes from a macro!).

[ehuss]

Sorry, I didn't mean to mislead. I wasn't advocating against this change. I was just pointing out in the discussion above that things had changed (for built-in attribute) as of 2 days ago, and people didn't seem to be aware.

[GuillaumeGomez]

Funny that @Ethiraric came across this just in the middle of this "change wave". :)

[petrochenkov]

The full list of test-like built-in attribute macros is cfg_eval, global_allocator, test_case, test and bench.
They should all behave in the same way with regards to duplicates.
(They can be found by searching for calls to check_builtin_macro_attribute.)

[Ethiraric]

Thank you for your review and pointers. Should I add the lint to all built-in attribute macros in this PR or open a new one?

[Ethiraric]

Updated the comment for the lint.

I think however the build fails because the snippet of code should be run with --test. I know not how to instruct the compiler to do so.

[petrochenkov]

I think however the build fails because the snippet of code should be run with --test. I know not how to instruct the compiler to do so.

You can use

```rust,ignore

for disabling the lint-docs check.

[Ethiraric]

Thanks for your review. I should have fixed all your requested changes!

[petrochenkov]

@bors r+

[bors]

📌 Commit 2be94d4 has been approved by petrochenkov