add trait impls to proc_macro::Ident

[Qelxiros]

ACP: rust-lang/libs-team#573

[rustbot]

r? @petrochenkov

rustbot has assigned @petrochenkov.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[rustbot]

Some changes occurred in src/tools/clippy

cc @rust-lang/clippy

[Qelxiros]

Clippy context: An aux crate (proc_macros.rs) was using Ident::to_string before comparing to a string literal, so I updated it to use the PartialEq implementation added in this PR.

[petrochenkov]

I suggest splitting this into one PR with (insta-stable) API changes, and then another PR with implementation optimizations.

Also, PartialEq impl for Ident was previously rejected (see #78634 and its linked issue) for the reasons that are still relevant now.
Comparisons with strings are ok, Hash is probably also ok, but not especially useful without Eq.

[Qelxiros]

To clarify, the clippy change was to fix CI.

Thanks for the context! I'd be happy to remove the PartialEq<Self> impl (and Eq, by extension) or modify it to compare spans as well if you think the rest is mergeable, or leave it as is pending further discussion. I'll also link your comment on the ACP for visibility.

[Qelxiros]

@rustbot ready

[petrochenkov]

and then another PR with implementation optimizations

This was about moving the code around and providing the optimized implementation instead of just doing .to_string().
I don't think it's necessary to add the new APIs.

The Hash impl is still questionable because it's inconsistent with the only PartialEq impl, but I'll leave this for the libs team to decide.
@rustbot author

[rustbot]

Reminder, once the PR becomes ready for a review, use @rustbot ready.

[Qelxiros]

@petrochenkov I'm a little confused. Do you mean that this implementation should be reduced to self.to_string() == other.as_ref()? That seems to miss the point of the ACP, which was to compare Idents with Strings (and friends) without an allocation.

[petrochenkov]

Do you mean that this implementation should be reduced to self.to_string() == other.as_ref()?

Yes.
Allocation or not is an implementation detail, that can be changed at any later point without any process or team decisions.

[petrochenkov]

Did you push the changes?
I still see all the unnecessary code moving and optimizations.

[Qelxiros]

@rustbot ready

[rustbot]

This PR was rebased onto a different master commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[Qelxiros]

@rustbot ready

I think I got rid of the unnecessary code moving, but I'm not sure what you're referring to as optimizations. Let me know what, if anything, I missed.

[petrochenkov]

but I'm not sure what you're referring to as optimizations

Everything outside of library/proc_macro/src/lib.rs.

[petrochenkov]

Anyway, I'm sending this to the libs-api team for approval.

This PR adds two public APIs:

• PartialEq with AsRef<str> for Ident
  • this should be ok from my point of view
• Hash for Ident
  • this is at least suspicious, because this Hash impl is inconsistent with the (nonexistent) PartialEq impl for the same type, not sure what is the library policy regarding such impls

[joshtriplett]

We took a brief look at this in today's @rust-lang/libs-api meeting. We didn't look at the Hash impl, but we looked at the PartialEq impl.

We observed that this is providing impl PartialEq<T> for ..., which is a blanket impl that we think would preclude people implementing PartialEq for their own types (without using negative impls). We don't have any other blanket PartialEq<T> impls in the standard library.

It'd be a bit more work, but please consider implementing PartialEq<SpecificType> for each specific type that currently implements AsRef<str>. (A macro should make that easy.)

[dtolnay]

We observed that this is providing impl PartialEq<T> for ..., which is a blanket impl that we think would preclude people implementing PartialEq for their own types (without using negative impls).

proc_macro2::Ident has this impl and it does not preclude having more PartialEq impls downstream.

https://docs.rs/proc-macro2/1.0.101/proc_macro2/struct.Ident.html#impl-PartialEq%3CT%3E-for-Ident
https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=91fd406853eede2540a45ec903f70fc6

Since you mentioned a negative impl, I assume that you expected this would only be allowed in combination with a impl !AsRef<str> for MyIdent {}. That is not the case.

The only thing it precludes is a custom PartialEq with some type that also implements AsRef<str> where you want PartialEq to be inconsistent with the standard library's AsRef-based impl, which seems fine.

[dtolnay]

• impl Hash for Ident — I am not sure that this is useful without impl PartialEq<Self> for Ident. Did we have a use case in mind? I am open to also adding PartialEq<Self> (and proc-macro2 already has it) but it was previously discussed and decided against in Implement PartialEq for Ident, PartialEq for TokenStream #51074.

• impl<T> PartialEq<T> for Ident where T: AsRef<str> + ?Sized — this is a breaking change for any type T that already has both PartialEq<T> for proc_macro::Ident and AsRef<str> for T. This is probably not widespread but I would not be surprised if somebody has done this, and if somebody has done it, there is a fair chance it is in some foundational proc macro helper library so the blast radius of breaking it could be unexpectedly big. A crater run might be called for.