Module rustc_data_structures::stable_hasher

source ·



  • Controls what data we do or do not hash. Whenever a HashStable implementation caches its result, it needs to include HashingControls as part of the key, to ensure that it does not produce an incorrect result (for example, using a Fingerprint produced while hashing Spans when a Fingerprint without Spans is being requested)
  • When hashing something that ends up affecting properties like symbol names, we want these symbol names to be calculated independently of other factors like what architecture you’re compiling from.


  • Something that implements HashStable<CTX> can be hashed in a way that is stable across multiple compilation sessions.
  • This is a companion trait to StableOrd. Some types like Symbol can be compared in a cross-session stable way, but their Ord implementation is not stable. In such cases, a StableOrd implementation can be provided to offer a lightweight way for stable sorting. (The more heavyweight option is to sort via ToStableHashKey, but then sorting needs to have access to a stable hashing context and ToStableHashKey can also be expensive as in the case of Symbol where it has to allocate a String.)
  • Trait for marking a type as having a sort order that is stable across compilation session boundaries. More formally:
  • Implement this for types that can be turned into stable keys like, for example, for DefId that can be converted to a DefPathHash. This is used for bringing maps into a predictable order before hashing them.