Tracking issue for `custom_attribute` features

[aturon]

Part of RFC 572. This issue tracks stabilization/deprecation.

[brson]

Is this feature ever going to be stabilized?

It is currently used by Rocket: rwf2/Rocket#19 (comment). Does Rocket have alternatives?

[steveklabnik]

Isn't this part of macros 2.0? that is #[proc_macro_attribute] https://github.com/rust-lang/rfcs/blob/master/text/1566-proc-macros.md

[beamspease]

Just found this ticket as serde's main documentation says to use it...
https://serde.rs/enum-representations.html

[thijsc]

It seems like serde relies on this feature a lot, see: https://serde.rs/attributes.html

Is the plan to stabilize this?

[scottmcm]

If this is no longer for rustc_attrs, I think there should be a PR to the gate list and unstable book to stop pointing here, and say why.

[nikomatsakis]

Discussed in the @rust-lang/lang meeting:

We believe we should remove the custom_attribute feature gate from the compiler. If I'm not mistaken, it allows the older behavior where you could use any attribute #[foo] anywhere. We don't — afaik — intend to go back to that world. Moreover, removing this feature would probably let us give more definitive and clear error messages that guide people towards using procedural macros.

I think this is the main chunk of code that would change:

rust/src/librustc_resolve/macros.rs

Lines 316 to 322 in daa53a5

	} else if !features.custom_attribute {
	let msg = format!("The attribute `{}` is currently unknown to the \
	compiler and may have meaning added to it in the \
	future", path);
	feature_err(&self.session.parse_sess, "custom_attribute", path.span,
	GateIssue::Language, &msg).emit();
	}

Nominating for @rust-lang/compiler mainly to see if anybody wants to follow-up or mentor this.