Skip to content

Inconsistent handling of #[derive] on invalid targets #78331

New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Closed
Aaron1011 opened this issue Oct 24, 2020 · 3 comments
Closed

Inconsistent handling of #[derive] on invalid targets #78331

Aaron1011 opened this issue Oct 24, 2020 · 3 comments
Labels
A-attributes Area: Attributes (`#[…]`, `#![…]`) A-macros Area: All kinds of macros (custom derive, macro_rules!, proc macros, ..) T-lang Relevant to the language team, which will review and decide on the PR/issue.

Comments

@Aaron1011
Copy link
Member

Aaron1011 commented Oct 24, 2020

The following code:

fn main() {
	struct Foo {}
	#[derive(Copy)] impl Foo {}
}

produces the following error

error[E0774]: `derive` may only be applied to structs, enums and unions
 --> src/main.rs:3:2
  |
3 |     #[derive(Copy)] impl Foo {}
  |     ^^^^^^^^^^^^^^^

However, applying #[derive] to a let statement just gives an "unused attribute" warning:

fn main() {
    #[derive(Copy)] let _ = 1;
}
warning: unused attribute
 --> src/main.rs:2:5
  |
2 |     #[derive(Copy)] let _ = 1;
  |     ^^^^^^^^^^^^^^^
  |
  = note: `#[warn(unused_attributes)]` on by default

A #[derive] attribute doesn't make any more sense on a statement than it does on an item. I think we should handle these two cases in the same way.

There's been a move towards forbidding attributes on targets that don't make sense: #77015. Unless anyone objects, I think we should consistently forbid #[derive] on all invalid targets.

@Aaron1011 Aaron1011 added A-attributes Area: Attributes (`#[…]`, `#![…]`) A-macros Area: All kinds of macros (custom derive, macro_rules!, proc macros, ..) T-lang Relevant to the language team, which will review and decide on the PR/issue. labels Oct 24, 2020
@Aaron1011
Copy link
Member Author

Aaron1011 commented Oct 24, 2020

The hard error dates back to 2014 (pre-1.0): ad61ff4#diff-b6281951b118c3ea5f37605f6b8bc76cb0406fff7a59d830c16c13e9d429f1d4R354-R357

The warnings (or ast least some of them) are more recent, dating back to 2018: #50092

@Aaron1011
Copy link
Member Author

I opened #78338 to do a Crater run, so we can see how much code is relying on this compiling.

@Aaron1011 Aaron1011 changed the title Incosistent handling of #[derive] on non-items Incosistent handling of #[derive] on invaid targets Oct 25, 2020
@Aaron1011 Aaron1011 changed the title Incosistent handling of #[derive] on invaid targets Incosistent handling of #[derive] on invalid targets Oct 25, 2020
@Aaron1011 Aaron1011 changed the title Incosistent handling of #[derive] on invalid targets Inconsistent handling of #[derive] on invalid targets Oct 25, 2020
@Aaron1011
Copy link
Member Author

This was turned into a hard error by #79078

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
A-attributes Area: Attributes (`#[…]`, `#![…]`) A-macros Area: All kinds of macros (custom derive, macro_rules!, proc macros, ..) T-lang Relevant to the language team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

1 participant