mirror of
https://github.com/rust-lang/rust.git
synced 2025-05-05 22:48:02 +00:00
76c500ec6c
Let a portion of DefPathHash uniquely identify the DefPath's crate. This allows to directly map from a `DefPathHash` to the crate it originates from, without constructing side tables to do that mapping -- something that is useful for incremental compilation where we deal with `DefPathHash` instead of `DefId` a lot. It also allows to reliably and cheaply check for `DefPathHash` collisions which allows the compiler to gracefully abort compilation instead of running into a subsequent ICE at some random place in the code. The following new piece of documentation describes the most interesting aspects of the changes: ```rust /// A `DefPathHash` is a fixed-size representation of a `DefPath` that is /// stable across crate and compilation session boundaries. It consists of two /// separate 64-bit hashes. The first uniquely identifies the crate this /// `DefPathHash` originates from (see [StableCrateId]), and the second /// uniquely identifies the corresponding `DefPath` within that crate. Together /// they form a unique identifier within an entire crate graph. /// /// There is a very small chance of hash collisions, which would mean that two /// different `DefPath`s map to the same `DefPathHash`. Proceeding compilation /// with such a hash collision would very probably lead to an ICE and, in the /// worst case, to a silent mis-compilation. The compiler therefore actively /// and exhaustively checks for such hash collisions and aborts compilation if /// it finds one. /// /// `DefPathHash` uses 64-bit hashes for both the crate-id part and the /// crate-internal part, even though it is likely that there are many more /// `LocalDefId`s in a single crate than there are individual crates in a crate /// graph. Since we use the same number of bits in both cases, the collision /// probability for the crate-local part will be quite a bit higher (though /// still very small). /// /// This imbalance is not by accident: A hash collision in the /// crate-local part of a `DefPathHash` will be detected and reported while /// compiling the crate in question. Such a collision does not depend on /// outside factors and can be easily fixed by the crate maintainer (e.g. by /// renaming the item in question or by bumping the crate version in a harmless /// way). /// /// A collision between crate-id hashes on the other hand is harder to fix /// because it depends on the set of crates in the entire crate graph of a /// compilation session. Again, using the same crate with a different version /// number would fix the issue with a high probability -- but that might be /// easier said then done if the crates in questions are dependencies of /// third-party crates. /// /// That being said, given a high quality hash function, the collision /// probabilities in question are very small. For example, for a big crate like /// `rustc_middle` (with ~50000 `LocalDefId`s as of the time of writing) there /// is a probability of roughly 1 in 14,750,000,000 of a crate-internal /// collision occurring. For a big crate graph with 1000 crates in it, there is /// a probability of 1 in 36,890,000,000,000 of a `StableCrateId` collision. ``` Given the probabilities involved I hope that no one will ever actually see the error messages. Nonetheless, I'd be glad about some feedback on how to improve them. Should we create a GH issue describing the problem and possible solutions to point to? Or a page in the rustc book? r? `@pnkfelix` (feel free to re-assign) |
||
|---|---|---|
| .. | ||
| base_n | ||
| binary_search_util | ||
| graph | ||
| obligation_forest | ||
| owning_ref | ||
| sip128 | ||
| small_c_str | ||
| snapshot_map | ||
| sorted_map | ||
| sso | ||
| stable_hasher | ||
| tagged_ptr | ||
| tiny_list | ||
| transitive_relation | ||
| atomic_ref.rs | ||
| base_n.rs | ||
| box_region.rs | ||
| captures.rs | ||
| fingerprint.rs | ||
| flock.rs | ||
| frozen.rs | ||
| functor.rs | ||
| fx.rs | ||
| jobserver.rs | ||
| lib.rs | ||
| macros.rs | ||
| map_in_place.rs | ||
| profiling.rs | ||
| ptr_key.rs | ||
| sharded.rs | ||
| sip128.rs | ||
| small_c_str.rs | ||
| sorted_map.rs | ||
| stable_hasher.rs | ||
| stable_map.rs | ||
| stable_set.rs | ||
| stack.rs | ||
| steal.rs | ||
| svh.rs | ||
| sync.rs | ||
| tagged_ptr.rs | ||
| temp_dir.rs | ||
| thin_vec.rs | ||
| tiny_list.rs | ||
| transitive_relation.rs | ||
| unhash.rs | ||
| vec_linked_list.rs | ||
| work_queue.rs | ||