Tracking issue for proc_macro::Ident::new_raw

[alexcrichton]

This API didn't get stabilized in the initial Macros 1.2 release because we wanted to be conservative. This API is unstable, though, and likely useful to others! This is a tracking issue for the API.

It's not clear to me if there's a blocker for stabilization other than we just wanted to make an explicit decision to stabilize the API.

[alexcrichton]

This is tracking the proc_macro_raw_ident feature

[chachi]

Stabilizing this feature would have a great impact on code generation for message libraries (e.g. in ROS) where message fields can collide with Rust keywords.

[petrochenkov]

@chachi
Since raw identifiers are already stabilized, I think the only question here is perhaps naming conventions (e.g. new_raw vs simply raw).

When introducing the function I thought new_adjective is not idiomatic, but apparently there are already NonNull::new_unchecked and Pin::new_unchecked, so Ident::new_raw is probably good too.
In this case the only thing that needs to be done is submitting a stabilization PR, that will then go through the formal team approval vote.

[chachi]

@petrochenkov Great! Is that something I could take care of? I haven't contributed to Rust upstream before so would love any tips/pointers on what that process is.

[petrochenkov]

@chachi

Is that something I could take care of?

Yes, for library stabilizations the only things that need to be done are changing the #[unstable(...)] attribute to #[stable(...)] (the version on trunk is 1.34.0 right now) and removing unnecessary #![feature(...)]s across the codebase.
Here's a recent example of such stabilization - #58576.

[adnanademovic]

@petrochenkov Should the feature be changed from "proc_macro_raw_ident" to something else, like "proc_macro_lib2"?

[petrochenkov]

@adnanademovic
No, the feature names are normally kept during stabilization.

[pwnorbitals]

It looks like this feature has been stabilized. Is this tracking issue still needed?

[petrochenkov]

No, it can be closed now.