You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Investigate usages of #[stable_hasher(project(name))] #91921
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.
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.
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
Activity
pierwill commentedon Dec 14, 2021
@rustbot claim
petrochenkov commentedon Dec 15, 2021
IIRC, it was done purely as a bug-compatibility measure when
Idents were introduced to HIR instead ofSymbols 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 commentedon Dec 22, 2021
This is now causing a bug - since we now serialize the full
AdtDefto disk, we may try to deserialize a staleExpnIdfrom a foreign crate, because we will incorrect end up thinking that anAdtDefis unchanged when one of itsSpanfields changes. See #92192Aaron1011 commentedon Feb 6, 2022
This was fixed in #92534, #93095, and #92533
pierwill commentedon Feb 6, 2022