Implement RFC 3107: #[derive(Default)] on enums with a #[default] attribute

[jhpratt]

This PR implements RFC 3107, which permits #[derive(Default)] on enums where a unit variant has a #[default] attribute. See comments for current status.

[rust-highfive]

r? @LeSeulArtichaut

(rust-highfive has picked a reviewer for you, use r? to override)

[jhpratt]

RFC for reference

[LeSeulArtichaut]

While this is in the compiler directory, I think this is technically under purview of the libs-api team as this could be done in user-provided code. Not sure who is best to review; both lang and libs-api were included for the RFC.

I think the implementation is a detail that doesn't matter to the lang or libs-api teams, this should be reviewed by the compiler team.

[LeSeulArtichaut]

One other thing that needs to be done (not sure how for this one — help welcome!) is "registering" the #[default] attribute with the compiler such that it doesn't complain about its mere existence.

You'll need to create the feature gate:

• declare the feature gate in compiler/rustc_feature/src/active.rs (see the dev-guide for more information)
• add a derive_default_enum symbol to be used as feature gate in compiler/rustc_span/src/symbol.rs

Once this is done, you should be able to define the attribute like this:

gated!(Default, AssumedUsed, template!(Word), derive_default_enum, experimental!(derive_default_enum)),

Apparently default is a weak keyword, so it's already declared as a symbol. You need to specify derive_default_enum in the 4th argument to declare that the feature gate is different from the name of the attribute (the last argument is only the message that is displayed when the attribute is used without the feature gate).

This should take care of checking that the attribute is only used on nightly, you don't have to manually implement it. However, you might want to implement a check to emit an error if the attribute is used outside an enum variant.

[jhpratt]

@rustbot label -T-libs-api +T-compiler

I found the page in the dev guide last night, and had it generally in the right place. When using the line you provided (a slight difference from what I had), I get the following error in a number of places

error[E0659]: `Default` is ambiguous (built-in attribute vs any other name)
  --> library/core/src/time.rs:63:61
   |
63 | #[derive(Clone, Copy, PartialEq, Eq, PartialOrd, Ord, Hash, Default)]
   |                                                             ^^^^^^^ ambiguous name
   |
   = note: `Default` could refer to a built-in attribute
note: `Default` could also refer to the derive macro imported here
  --> library/core/src/prelude/v1.rs:32:9
   |
32 | pub use crate::default::Default;
   |         ^^^^^^^^^^^^^^^^^^^^^^^

Given that sym::Default maps to default, I'm not sure why this is the case (symbols appear to be case sensitive).

While it may work by declaring the attribute globally and erroring if it's used in certain places, it feels like it should be better if there's a way for the derive to declare the attribute belongs to it. I presume this is possible given that it's exposed for proc_macro derives, but I was unable to find where this is actually implemented.

[LeSeulArtichaut]

I guess this proves I'm not the right reviewer here, r? @petrochenkov maybe

[jhpratt]

Changes have been made.

[jhpratt]

The RFC has been merged. cc @petrochenkov

[petrochenkov]

@bors r+

[bors]

📌 Commit 7f036962daeaa8210a109441112474bc9a58f6cf has been approved by petrochenkov

[jhpratt]

Rebased. Also bumped to 1.56 given the 1.55 beta has been cut.

[petrochenkov]

@bors r+

[bors]

📌 Commit 72465b0 has been approved by petrochenkov

[bors]

⌛ Testing commit 72465b0 with merge aea2e44...

[bors]

☀️ Test successful - checks-actions
Approved by: petrochenkov
Pushing aea2e44 to master...