rust/compiler/rustc_hir/src/stable_hash_impls.rs, branch 1.68.2

Rename some `OwnerId` fields.

2022-10-29T09:28:38+00:00

spastorino noticed some silly expressions like `item_id.def_id.def_id`. This commit renames several `def_id: OwnerId` fields as `owner_id`, so those expressions become `item_id.owner_id.def_id`. `item_id.owner_id.local_def_id` would be even clearer, but the use of `def_id` for values of type `LocalDefId` is *very* widespread, so I left that alone.

separate definitions and `HIR` owners

2022-09-24T14:21:19+00:00

fix a ui test use `into` fix clippy ui test fix a run-make-fulldeps test implement `IntoQueryParam` for `OwnerId` use `OwnerId` for more queries change the type of `ParentOwnerIterator::Item` to `(OwnerId, OwnerNode)`

Derive HashStable for HIR Expr and Ty.

2022-08-07T15:30:45+00:00

Remove NodeIdHashingMode.

2022-04-12T17:59:32+00:00

Rollup merge of #93443 - spastorino:add-stable-hash-impl-doc, r=cjgillot

2022-02-11T06:48:03+00:00

Add comment on stable_hash_impl for OwnerNodes r? `@cjgillot` cc `@oli-obk` `@bors` rollup=always

Remove defaultness from ImplItem.

2022-02-03T17:56:08+00:00

Add comment on stable_hash_impl for OwnerNodes

2022-01-28T21:06:53+00:00

Store hir_id_to_def_id in OwnerInfo.

2022-01-25T18:05:19+00:00

Remove special-cased stable hashing for HIR module

2021-12-24T17:38:29+00:00

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`.

Remove `in_band_lifetimes` from `rustc_hir`

2021-12-14T04:33:53+00:00