Stabilize Ident::new_raw

[adnanademovic]

Tracking issue: #54723

[rust-highfive]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @alexcrichton (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

[alexcrichton]

There's some discussion about stabilization in the tracking issue and it looks like one of the main questions is about the name of the API (Ident::new_raw, Ident::raw, etc). @petrochenkov notes that raw identifiers are now stabilized which was one of the main reasons (IIRC) for not stabilizing this from before.

In light of all that I'd personally be in favor of the current new_raw name and would like to propose stabilization! I've tagged T-libs for the API aspect and T-lang as well because they were tagged on the tracking issue. If T-lang y'all don't feel you need to sign off, I'll cancel and re-issue FCP!

@rfcbot fcp merge

[rfcbot]

Team member @alexcrichton has proposed to merge this. The next step is review by the rest of the tagged team members:

• @Amanieu
• @Centril
• @Kimundi
• @SimonSapin
• @alexcrichton
• @aturon
• @cramertj
• @dtolnay
• @eddyb
• @joshtriplett
• @nikomatsakis
• @pnkfelix
• @scottmcm
• @sfackler
• @withoutboats

Concerns:

• tests-and-clearer-docs (Stabilize Ident::new_raw #59002 (comment))

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[Centril]

(Including T-Lang on this was proper as this exposes language features programmatically...)

I agree that the name is fine; I would also be alright with Ident::new -- either way works and it's not a big deal either way.

I do however think that the documentation on the function is a bit underwhelming; In particular, the semantics of new_raw is unclear wrt. panics (e.g. for r#self... -- cc @petrochenkov). On the subject of clear semantics, I'd also like to be pointed towards the set of tests (run-pass, run-fail, etc.) that provide checks on the semantics... To that end:

@rfcbot concern tests-and-clearer-docs

[Centril]

ping @adnanademovic @alexcrichton re. my request for clearer docs and a list of tests ^---

[cramertj]

Ping again for docs, tests so we can stabilize.

[petrochenkov]

One more line:

/// In addition to general identifier validity requirements, raw identifiers cannot be created for keywords usable in path segments (`self`, `super` and others).

[Centril]

That leaves me somewhat confused; what does "general identifier validity requirements" entail here? Surely Ident::new_raw has fewer restrictions than Ident::new_raw but your wording suggests it has more -- in particular, when will Ident::new_raw panic?

[petrochenkov]

"general identifier validity requirements" -> "general identifier validity requirements inherited from Ident::new".
We can point to the reference or something that describes what is an identifier.

Surely Ident::new_raw has fewer restrictions than Ident::new_raw but your wording suggests it has more

It does have more restrictions.

in particular, when will Ident::new_raw panic?

"raw identifiers cannot be created for" -> "this function will panic on attempts to create"

[Centril]

It does have more restrictions.

Ah! $ident accepts keywords as well whereas it does not accept r#self -- that's pretty counter-intuitive. I think amending the documentation of fn new would be good as well to note the fact that keywords are allowed.

[petrochenkov]

Tests that need to be added:

• Proc-macro-generated struct r#fn; parses and creates a usable struct named r#fn.
• Proc-macro-generated r#struct S; doesn't parse.
• Proc-macro-generated struct r#S; parses and creates a usable struct named S.

Existing tests:

• Cannot create a raw identifier from a path segment keyword - ui/proc-macro/invalid-punct-ident-3.rs.
• Non proc-macro-generated raw identifiers are pretty thoroughly tested, search r#\w in src/test/**/*.rs for examples.

[Dylan-DPC-zz]

@adnanademovic any updates on this?

[JohnCSimon]

Ping from triage:
@adnanademovic Can you please provide an update on the status of this PR
cc: @petrochenkov @Centril
Thank you!

[JohnCSimon]

Pinging from triage:
@adnanademovic Can you please provide an update on the status of this PR?

Thank you.

[adnanademovic]

Hi, sorry for the lack of response. I was extremely busy. If the 3 tests are all it's needed, I'll try to do it in the next few days. I just have to go learn how to actually compile tests!

[joshtriplett]

(Checking @aturon's box, as he's no longer on the lang team.)

[hdhoang]

ping from triage @adnanademovic, any updates on this?

[Dylan-DPC-zz]

Closing this since it has been inactive for a long time. Thanks for the effort :)