bors 2b681ac06b Auto merge of #92259 - Aaron1011:normal-mod-hashing, r=michaelwoerister ... Remove special-cased stable hashing for HIR module All other 'containers' (e.g. `impl` blocks) hashed their contents in the normal, order-dependent way. However, `Mod` was hashing its contents in a (sort-of) order-independent way. However, the exact order is exposed to consumers through `Mod.item_ids`, and through query results like `hir_module_items`. Therefore, stable hashing needs to take the order of items into account, to avoid fingerprint ICEs. Unforuntately, I was unable to directly build a reproducer for the ICE, due to the behavior of `Fingerprint::combine_commutative`. This operation swaps the upper and lower `u64` when constructing the result, which makes the function non-associative. Since we start the hashing of module items by combining `Fingerprint::ZERO` with the first item, it's difficult to actually build an example where changing the order of module items leaves the final hash unchanged. However, this appears to have been hit in practice in #92218 While we're not able to reproduce it, the fact that proc-macros are involved (which can give an entire module the same span, preventing any span-related invalidations) makes me confident that the root cause of that issue is our method of hashing module items. This PR removes all of the special handling for `Mod`, instead deriving a `HashStable` implementation. This makes `Mod` consistent with other 'contains' like `Impl`, which hash their contents through the typical derive of `HashStable`.		2022-01-04 00:25:23 +00:00
..
dep_graph	Add #[rustc_clean(loaded_from_disk)] to assert loading of query result	2021-12-21 16:34:12 -05:00
ich	Remove special-cased stable hashing for HIR module	2021-12-24 12:38:29 -05:00
query	Add #[rustc_clean(loaded_from_disk)] to assert loading of query result	2021-12-21 16:34:12 -05:00
cache.rs	Remove (lots of) dead code	2021-03-27 22:16:33 -04:00
lib.rs	Stabilize iter::zip.	2021-12-14 18:50:31 -04:00