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

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

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in 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