Investigate usages of `#[stable_hasher(project(name))]`

[Aaron1011]

In several places, we use #[stable_hasher(project(name))] to skip hashing the Span of an Ident. For example:

rust/compiler/rustc_hir/src/hir.rs

Lines 205 to 209 in 404c847

	#[derive(Debug, HashStable_Generic)]
	pub struct PathSegment<'hir> {
	/// The identifier portion of this path segment.
	#[stable_hasher(project(name))]
	pub ident: Ident,

It's not obvious why this is correct. Assuming that this isn't causing any issues with incr comp invalidation, then we should add comments explaining why this is the right thing to do.

[pierwill]

@rustbot claim

[petrochenkov]

IIRC, it was done purely as a bug-compatibility measure when Idents were introduced to HIR instead of Symbols to support hygiene.
Hashing spans caused either incremental errors or perf regressions.
This was long ago, so the issues preventing span hashing may be fixed now, we need to try to remove this annotations and check what happens.

[Aaron1011]

This is now causing a bug - since we now serialize the full AdtDef to disk, we may try to deserialize a stale ExpnId from a foreign crate, because we will incorrect end up thinking that an AdtDef is unchanged when one of its Span fields changes. See #92192

[Aaron1011]

This was fixed in #92534, #93095, and #92533

[pierwill]

@rustbot release-assignment