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)
70 lines
1.7 KiB
Rust
70 lines
1.7 KiB
Rust
//! The Rust parser and macro expander.
|
|
//!
|
|
//! # Note
|
|
//!
|
|
//! This API is completely unstable and subject to change.
|
|
|
|
#![doc(
|
|
html_root_url = "https://doc.rust-lang.org/nightly/nightly-rustc/",
|
|
test(attr(deny(warnings)))
|
|
)]
|
|
#![feature(box_syntax)]
|
|
#![feature(box_patterns)]
|
|
#![feature(const_fn)] // For the `transmute` in `P::new`
|
|
#![feature(const_fn_transmute)]
|
|
#![feature(const_panic)]
|
|
#![feature(crate_visibility_modifier)]
|
|
#![feature(label_break_value)]
|
|
#![feature(nll)]
|
|
#![feature(or_patterns)]
|
|
#![recursion_limit = "256"]
|
|
|
|
#[macro_use]
|
|
extern crate rustc_macros;
|
|
|
|
#[macro_export]
|
|
macro_rules! unwrap_or {
|
|
($opt:expr, $default:expr) => {
|
|
match $opt {
|
|
Some(x) => x,
|
|
None => $default,
|
|
}
|
|
};
|
|
}
|
|
|
|
pub mod util {
|
|
pub mod classify;
|
|
pub mod comments;
|
|
pub mod literal;
|
|
pub mod parser;
|
|
}
|
|
|
|
pub mod ast;
|
|
pub mod ast_like;
|
|
pub mod attr;
|
|
pub mod entry;
|
|
pub mod expand;
|
|
pub mod mut_visit;
|
|
pub mod node_id;
|
|
pub mod ptr;
|
|
pub mod token;
|
|
pub mod tokenstream;
|
|
pub mod visit;
|
|
|
|
pub use self::ast::*;
|
|
pub use self::ast_like::AstLike;
|
|
|
|
use rustc_data_structures::stable_hasher::{HashStable, StableHasher};
|
|
|
|
/// Requirements for a `StableHashingContext` to be used in this crate.
|
|
/// This is a hack to allow using the `HashStable_Generic` derive macro
|
|
/// instead of implementing everything in librustc_middle.
|
|
pub trait HashStableContext: rustc_span::HashStableContext {
|
|
fn hash_attr(&mut self, _: &ast::Attribute, hasher: &mut StableHasher);
|
|
}
|
|
|
|
impl<AstCtx: crate::HashStableContext> HashStable<AstCtx> for ast::Attribute {
|
|
fn hash_stable(&self, hcx: &mut AstCtx, hasher: &mut StableHasher) {
|
|
hcx.hash_attr(self, hasher)
|
|
}
|
|
}
|