2014-02-24 21:45:20 -06:00
|
|
|
// Copyright 2012-2014 The Rust Project Developers. See the COPYRIGHT
|
|
|
|
// file at the top-level directory of this distribution and at
|
|
|
|
// http://rust-lang.org/COPYRIGHT.
|
|
|
|
//
|
|
|
|
// Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or
|
|
|
|
// http://www.apache.org/licenses/LICENSE-2.0> or the MIT license
|
|
|
|
// <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your
|
|
|
|
// option. This file may not be copied, modified, or distributed
|
|
|
|
// except according to those terms.
|
|
|
|
|
|
|
|
//! Calculation and management of a Strict Version Hash for crates
|
|
|
|
//!
|
|
|
|
//! # Today's ABI problem
|
|
|
|
//!
|
|
|
|
//! In today's implementation of rustc, it is incredibly difficult to achieve
|
|
|
|
//! forward binary compatibility without resorting to C-like interfaces. Within
|
|
|
|
//! rust code itself, abi details such as symbol names suffer from a variety of
|
|
|
|
//! unrelated factors to code changing such as the "def id drift" problem. This
|
|
|
|
//! ends up yielding confusing error messages about metadata mismatches and
|
|
|
|
//! such.
|
|
|
|
//!
|
2014-03-06 01:35:12 -06:00
|
|
|
//! The core of this problem is when an upstream dependency changes and
|
2014-04-20 23:49:39 -05:00
|
|
|
//! downstream dependents are not recompiled. This causes compile errors because
|
2014-02-24 21:45:20 -06:00
|
|
|
//! the upstream crate's metadata has changed but the downstream crates are
|
|
|
|
//! still referencing the older crate's metadata.
|
|
|
|
//!
|
|
|
|
//! This problem exists for many reasons, the primary of which is that rust does
|
|
|
|
//! not currently support forwards ABI compatibility (in place upgrades of a
|
|
|
|
//! crate).
|
|
|
|
//!
|
|
|
|
//! # SVH and how it alleviates the problem
|
|
|
|
//!
|
|
|
|
//! With all of this knowledge on hand, this module contains the implementation
|
|
|
|
//! of a notion of a "Strict Version Hash" for a crate. This is essentially a
|
|
|
|
//! hash of all contents of a crate which can somehow be exposed to downstream
|
|
|
|
//! crates.
|
|
|
|
//!
|
|
|
|
//! This hash is currently calculated by just hashing the AST, but this is
|
|
|
|
//! obviously wrong (doc changes should not result in an incompatible ABI).
|
|
|
|
//! Implementation-wise, this is required at this moment in time.
|
|
|
|
//!
|
|
|
|
//! By encoding this strict version hash into all crate's metadata, stale crates
|
|
|
|
//! can be detected immediately and error'd about by rustc itself.
|
|
|
|
//!
|
|
|
|
//! # Relevant links
|
|
|
|
//!
|
2014-06-16 18:07:34 -05:00
|
|
|
//! Original issue: https://github.com/rust-lang/rust/issues/10207
|
2014-02-24 21:45:20 -06:00
|
|
|
|
|
|
|
use std::fmt;
|
std: Stabilize the std::hash module
This commit aims to prepare the `std::hash` module for alpha by formalizing its
current interface whileholding off on adding `#[stable]` to the new APIs. The
current usage with the `HashMap` and `HashSet` types is also reconciled by
separating out composable parts of the design. The primary goal of this slight
redesign is to separate the concepts of a hasher's state from a hashing
algorithm itself.
The primary change of this commit is to separate the `Hasher` trait into a
`Hasher` and a `HashState` trait. Conceptually the old `Hasher` trait was
actually just a factory for various states, but hashing had very little control
over how these states were used. Additionally the old `Hasher` trait was
actually fairly unrelated to hashing.
This commit redesigns the existing `Hasher` trait to match what the notion of a
`Hasher` normally implies with the following definition:
trait Hasher {
type Output;
fn reset(&mut self);
fn finish(&self) -> Output;
}
This `Hasher` trait emphasizes that hashing algorithms may produce outputs other
than a `u64`, so the output type is made generic. Other than that, however, very
little is assumed about a particular hasher. It is left up to implementors to
provide specific methods or trait implementations to feed data into a hasher.
The corresponding `Hash` trait becomes:
trait Hash<H: Hasher> {
fn hash(&self, &mut H);
}
The old default of `SipState` was removed from this trait as it's not something
that we're willing to stabilize until the end of time, but the type parameter is
always required to implement `Hasher`. Note that the type parameter `H` remains
on the trait to enable multidispatch for specialization of hashing for
particular hashers.
Note that `Writer` is not mentioned in either of `Hash` or `Hasher`, it is
simply used as part `derive` and the implementations for all primitive types.
With these definitions, the old `Hasher` trait is realized as a new `HashState`
trait in the `collections::hash_state` module as an unstable addition for
now. The current definition looks like:
trait HashState {
type Hasher: Hasher;
fn hasher(&self) -> Hasher;
}
The purpose of this trait is to emphasize that the one piece of functionality
for implementors is that new instances of `Hasher` can be created. This
conceptually represents the two keys from which more instances of a
`SipHasher` can be created, and a `HashState` is what's stored in a
`HashMap`, not a `Hasher`.
Implementors of custom hash algorithms should implement the `Hasher` trait, and
only hash algorithms intended for use in hash maps need to implement or worry
about the `HashState` trait.
The entire module and `HashState` infrastructure remains `#[unstable]` due to it
being recently redesigned, but some other stability decision made for the
`std::hash` module are:
* The `Writer` trait remains `#[experimental]` as it's intended to be replaced
with an `io::Writer` (more details soon).
* The top-level `hash` function is `#[unstable]` as it is intended to be generic
over the hashing algorithm instead of hardwired to `SipHasher`
* The inner `sip` module is now private as its one export, `SipHasher` is
reexported in the `hash` module.
And finally, a few changes were made to the default parameters on `HashMap`.
* The `RandomSipHasher` default type parameter was renamed to `RandomState`.
This renaming emphasizes that it is not a hasher, but rather just state to
generate hashers. It also moves away from the name "sip" as it may not always
be implemented as `SipHasher`. This type lives in the
`std::collections::hash_map` module as `#[unstable]`
* The associated `Hasher` type of `RandomState` is creatively called...
`Hasher`! This concrete structure lives next to `RandomState` as an
implemenation of the "default hashing algorithm" used for a `HashMap`. Under
the hood this is currently implemented as `SipHasher`, but it draws an
explicit interface for now and allows us to modify the implementation over
time if necessary.
There are many breaking changes outlined above, and as a result this commit is
a:
[breaking-change]
2014-12-09 14:37:23 -06:00
|
|
|
use std::hash::{Hash, SipHasher, Hasher};
|
2014-02-24 21:45:20 -06:00
|
|
|
use std::iter::range_step;
|
|
|
|
use syntax::ast;
|
2014-05-12 12:11:46 -05:00
|
|
|
use syntax::visit;
|
2014-02-24 21:45:20 -06:00
|
|
|
|
2015-01-28 07:34:18 -06:00
|
|
|
#[derive(Clone, PartialEq, Debug)]
|
2014-02-24 21:45:20 -06:00
|
|
|
pub struct Svh {
|
2014-05-22 18:57:53 -05:00
|
|
|
hash: String,
|
2014-02-24 21:45:20 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
impl Svh {
|
|
|
|
pub fn new(hash: &str) -> Svh {
|
|
|
|
assert!(hash.len() == 16);
|
2014-05-25 05:17:19 -05:00
|
|
|
Svh { hash: hash.to_string() }
|
2014-02-24 21:45:20 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
pub fn as_str<'a>(&'a self) -> &'a str {
|
2015-02-20 13:08:14 -06:00
|
|
|
&self.hash
|
2014-02-24 21:45:20 -06:00
|
|
|
}
|
|
|
|
|
2014-07-04 21:41:54 -05:00
|
|
|
pub fn calculate(metadata: &Vec<String>, krate: &ast::Crate) -> Svh {
|
2014-05-12 12:11:46 -05:00
|
|
|
// FIXME (#14132): This is better than it used to be, but it still not
|
|
|
|
// ideal. We now attempt to hash only the relevant portions of the
|
|
|
|
// Crate AST as well as the top-level crate attributes. (However,
|
|
|
|
// the hashing of the crate attributes should be double-checked
|
|
|
|
// to ensure it is not incorporating implementation artifacts into
|
|
|
|
// the hash that are not otherwise visible.)
|
|
|
|
|
2014-02-24 21:45:20 -06:00
|
|
|
// FIXME: this should use SHA1, not SipHash. SipHash is not built to
|
|
|
|
// avoid collisions.
|
std: Stabilize the std::hash module
This commit aims to prepare the `std::hash` module for alpha by formalizing its
current interface whileholding off on adding `#[stable]` to the new APIs. The
current usage with the `HashMap` and `HashSet` types is also reconciled by
separating out composable parts of the design. The primary goal of this slight
redesign is to separate the concepts of a hasher's state from a hashing
algorithm itself.
The primary change of this commit is to separate the `Hasher` trait into a
`Hasher` and a `HashState` trait. Conceptually the old `Hasher` trait was
actually just a factory for various states, but hashing had very little control
over how these states were used. Additionally the old `Hasher` trait was
actually fairly unrelated to hashing.
This commit redesigns the existing `Hasher` trait to match what the notion of a
`Hasher` normally implies with the following definition:
trait Hasher {
type Output;
fn reset(&mut self);
fn finish(&self) -> Output;
}
This `Hasher` trait emphasizes that hashing algorithms may produce outputs other
than a `u64`, so the output type is made generic. Other than that, however, very
little is assumed about a particular hasher. It is left up to implementors to
provide specific methods or trait implementations to feed data into a hasher.
The corresponding `Hash` trait becomes:
trait Hash<H: Hasher> {
fn hash(&self, &mut H);
}
The old default of `SipState` was removed from this trait as it's not something
that we're willing to stabilize until the end of time, but the type parameter is
always required to implement `Hasher`. Note that the type parameter `H` remains
on the trait to enable multidispatch for specialization of hashing for
particular hashers.
Note that `Writer` is not mentioned in either of `Hash` or `Hasher`, it is
simply used as part `derive` and the implementations for all primitive types.
With these definitions, the old `Hasher` trait is realized as a new `HashState`
trait in the `collections::hash_state` module as an unstable addition for
now. The current definition looks like:
trait HashState {
type Hasher: Hasher;
fn hasher(&self) -> Hasher;
}
The purpose of this trait is to emphasize that the one piece of functionality
for implementors is that new instances of `Hasher` can be created. This
conceptually represents the two keys from which more instances of a
`SipHasher` can be created, and a `HashState` is what's stored in a
`HashMap`, not a `Hasher`.
Implementors of custom hash algorithms should implement the `Hasher` trait, and
only hash algorithms intended for use in hash maps need to implement or worry
about the `HashState` trait.
The entire module and `HashState` infrastructure remains `#[unstable]` due to it
being recently redesigned, but some other stability decision made for the
`std::hash` module are:
* The `Writer` trait remains `#[experimental]` as it's intended to be replaced
with an `io::Writer` (more details soon).
* The top-level `hash` function is `#[unstable]` as it is intended to be generic
over the hashing algorithm instead of hardwired to `SipHasher`
* The inner `sip` module is now private as its one export, `SipHasher` is
reexported in the `hash` module.
And finally, a few changes were made to the default parameters on `HashMap`.
* The `RandomSipHasher` default type parameter was renamed to `RandomState`.
This renaming emphasizes that it is not a hasher, but rather just state to
generate hashers. It also moves away from the name "sip" as it may not always
be implemented as `SipHasher`. This type lives in the
`std::collections::hash_map` module as `#[unstable]`
* The associated `Hasher` type of `RandomState` is creatively called...
`Hasher`! This concrete structure lives next to `RandomState` as an
implemenation of the "default hashing algorithm" used for a `HashMap`. Under
the hood this is currently implemented as `SipHasher`, but it draws an
explicit interface for now and allows us to modify the implementation over
time if necessary.
There are many breaking changes outlined above, and as a result this commit is
a:
[breaking-change]
2014-12-09 14:37:23 -06:00
|
|
|
let mut state = SipHasher::new();
|
2014-05-12 12:11:46 -05:00
|
|
|
|
2015-01-31 11:20:46 -06:00
|
|
|
for data in metadata {
|
2014-07-01 10:37:54 -05:00
|
|
|
data.hash(&mut state);
|
|
|
|
}
|
|
|
|
|
2014-05-12 12:11:46 -05:00
|
|
|
{
|
|
|
|
let mut visit = svh_visitor::make(&mut state);
|
2014-09-12 05:10:30 -05:00
|
|
|
visit::walk_crate(&mut visit, krate);
|
2014-05-12 12:11:46 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
// FIXME (#14132): This hash is still sensitive to e.g. the
|
|
|
|
// spans of the crate Attributes and their underlying
|
|
|
|
// MetaItems; we should make ContentHashable impl for those
|
|
|
|
// types and then use hash_content. But, since all crate
|
|
|
|
// attributes should appear near beginning of the file, it is
|
|
|
|
// not such a big deal to be sensitive to their spans for now.
|
2014-05-20 02:07:24 -05:00
|
|
|
//
|
|
|
|
// We hash only the MetaItems instead of the entire Attribute
|
|
|
|
// to avoid hashing the AttrId
|
2015-01-31 11:20:46 -06:00
|
|
|
for attr in &krate.attrs {
|
2014-05-20 02:07:24 -05:00
|
|
|
attr.node.value.hash(&mut state);
|
|
|
|
}
|
2014-02-24 21:45:20 -06:00
|
|
|
|
std: Stabilize the std::hash module
This commit aims to prepare the `std::hash` module for alpha by formalizing its
current interface whileholding off on adding `#[stable]` to the new APIs. The
current usage with the `HashMap` and `HashSet` types is also reconciled by
separating out composable parts of the design. The primary goal of this slight
redesign is to separate the concepts of a hasher's state from a hashing
algorithm itself.
The primary change of this commit is to separate the `Hasher` trait into a
`Hasher` and a `HashState` trait. Conceptually the old `Hasher` trait was
actually just a factory for various states, but hashing had very little control
over how these states were used. Additionally the old `Hasher` trait was
actually fairly unrelated to hashing.
This commit redesigns the existing `Hasher` trait to match what the notion of a
`Hasher` normally implies with the following definition:
trait Hasher {
type Output;
fn reset(&mut self);
fn finish(&self) -> Output;
}
This `Hasher` trait emphasizes that hashing algorithms may produce outputs other
than a `u64`, so the output type is made generic. Other than that, however, very
little is assumed about a particular hasher. It is left up to implementors to
provide specific methods or trait implementations to feed data into a hasher.
The corresponding `Hash` trait becomes:
trait Hash<H: Hasher> {
fn hash(&self, &mut H);
}
The old default of `SipState` was removed from this trait as it's not something
that we're willing to stabilize until the end of time, but the type parameter is
always required to implement `Hasher`. Note that the type parameter `H` remains
on the trait to enable multidispatch for specialization of hashing for
particular hashers.
Note that `Writer` is not mentioned in either of `Hash` or `Hasher`, it is
simply used as part `derive` and the implementations for all primitive types.
With these definitions, the old `Hasher` trait is realized as a new `HashState`
trait in the `collections::hash_state` module as an unstable addition for
now. The current definition looks like:
trait HashState {
type Hasher: Hasher;
fn hasher(&self) -> Hasher;
}
The purpose of this trait is to emphasize that the one piece of functionality
for implementors is that new instances of `Hasher` can be created. This
conceptually represents the two keys from which more instances of a
`SipHasher` can be created, and a `HashState` is what's stored in a
`HashMap`, not a `Hasher`.
Implementors of custom hash algorithms should implement the `Hasher` trait, and
only hash algorithms intended for use in hash maps need to implement or worry
about the `HashState` trait.
The entire module and `HashState` infrastructure remains `#[unstable]` due to it
being recently redesigned, but some other stability decision made for the
`std::hash` module are:
* The `Writer` trait remains `#[experimental]` as it's intended to be replaced
with an `io::Writer` (more details soon).
* The top-level `hash` function is `#[unstable]` as it is intended to be generic
over the hashing algorithm instead of hardwired to `SipHasher`
* The inner `sip` module is now private as its one export, `SipHasher` is
reexported in the `hash` module.
And finally, a few changes were made to the default parameters on `HashMap`.
* The `RandomSipHasher` default type parameter was renamed to `RandomState`.
This renaming emphasizes that it is not a hasher, but rather just state to
generate hashers. It also moves away from the name "sip" as it may not always
be implemented as `SipHasher`. This type lives in the
`std::collections::hash_map` module as `#[unstable]`
* The associated `Hasher` type of `RandomState` is creatively called...
`Hasher`! This concrete structure lives next to `RandomState` as an
implemenation of the "default hashing algorithm" used for a `HashMap`. Under
the hood this is currently implemented as `SipHasher`, but it draws an
explicit interface for now and allows us to modify the implementation over
time if necessary.
There are many breaking changes outlined above, and as a result this commit is
a:
[breaking-change]
2014-12-09 14:37:23 -06:00
|
|
|
let hash = state.finish();
|
2014-02-24 21:45:20 -06:00
|
|
|
return Svh {
|
2015-01-24 08:39:32 -06:00
|
|
|
hash: range_step(0, 64, 4).map(|i| hex(hash >> i)).collect()
|
2014-02-24 21:45:20 -06:00
|
|
|
};
|
|
|
|
|
|
|
|
fn hex(b: u64) -> char {
|
|
|
|
let b = (b & 0xf) as u8;
|
|
|
|
let b = match b {
|
2014-09-26 23:13:20 -05:00
|
|
|
0 ... 9 => '0' as u8 + b,
|
2014-02-24 21:45:20 -06:00
|
|
|
_ => 'a' as u8 + b - 10,
|
|
|
|
};
|
|
|
|
b as char
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-01-20 17:45:07 -06:00
|
|
|
impl fmt::Display for Svh {
|
2014-02-24 21:45:20 -06:00
|
|
|
fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result {
|
|
|
|
f.pad(self.as_str())
|
|
|
|
}
|
|
|
|
}
|
2014-05-12 12:11:46 -05:00
|
|
|
|
|
|
|
// FIXME (#14132): Even this SVH computation still has implementation
|
|
|
|
// artifacts: namely, the order of item declaration will affect the
|
|
|
|
// hash computation, but for many kinds of items the order of
|
|
|
|
// declaration should be irrelevant to the ABI.
|
|
|
|
|
|
|
|
mod svh_visitor {
|
2014-11-06 02:05:53 -06:00
|
|
|
pub use self::SawExprComponent::*;
|
|
|
|
pub use self::SawStmtComponent::*;
|
|
|
|
use self::SawAbiComponent::*;
|
2014-05-12 12:11:46 -05:00
|
|
|
use syntax::ast;
|
|
|
|
use syntax::ast::*;
|
|
|
|
use syntax::codemap::Span;
|
|
|
|
use syntax::parse::token;
|
|
|
|
use syntax::print::pprust;
|
|
|
|
use syntax::visit;
|
|
|
|
use syntax::visit::{Visitor, FnKind};
|
|
|
|
|
std: Stabilize the std::hash module
This commit aims to prepare the `std::hash` module for alpha by formalizing its
current interface whileholding off on adding `#[stable]` to the new APIs. The
current usage with the `HashMap` and `HashSet` types is also reconciled by
separating out composable parts of the design. The primary goal of this slight
redesign is to separate the concepts of a hasher's state from a hashing
algorithm itself.
The primary change of this commit is to separate the `Hasher` trait into a
`Hasher` and a `HashState` trait. Conceptually the old `Hasher` trait was
actually just a factory for various states, but hashing had very little control
over how these states were used. Additionally the old `Hasher` trait was
actually fairly unrelated to hashing.
This commit redesigns the existing `Hasher` trait to match what the notion of a
`Hasher` normally implies with the following definition:
trait Hasher {
type Output;
fn reset(&mut self);
fn finish(&self) -> Output;
}
This `Hasher` trait emphasizes that hashing algorithms may produce outputs other
than a `u64`, so the output type is made generic. Other than that, however, very
little is assumed about a particular hasher. It is left up to implementors to
provide specific methods or trait implementations to feed data into a hasher.
The corresponding `Hash` trait becomes:
trait Hash<H: Hasher> {
fn hash(&self, &mut H);
}
The old default of `SipState` was removed from this trait as it's not something
that we're willing to stabilize until the end of time, but the type parameter is
always required to implement `Hasher`. Note that the type parameter `H` remains
on the trait to enable multidispatch for specialization of hashing for
particular hashers.
Note that `Writer` is not mentioned in either of `Hash` or `Hasher`, it is
simply used as part `derive` and the implementations for all primitive types.
With these definitions, the old `Hasher` trait is realized as a new `HashState`
trait in the `collections::hash_state` module as an unstable addition for
now. The current definition looks like:
trait HashState {
type Hasher: Hasher;
fn hasher(&self) -> Hasher;
}
The purpose of this trait is to emphasize that the one piece of functionality
for implementors is that new instances of `Hasher` can be created. This
conceptually represents the two keys from which more instances of a
`SipHasher` can be created, and a `HashState` is what's stored in a
`HashMap`, not a `Hasher`.
Implementors of custom hash algorithms should implement the `Hasher` trait, and
only hash algorithms intended for use in hash maps need to implement or worry
about the `HashState` trait.
The entire module and `HashState` infrastructure remains `#[unstable]` due to it
being recently redesigned, but some other stability decision made for the
`std::hash` module are:
* The `Writer` trait remains `#[experimental]` as it's intended to be replaced
with an `io::Writer` (more details soon).
* The top-level `hash` function is `#[unstable]` as it is intended to be generic
over the hashing algorithm instead of hardwired to `SipHasher`
* The inner `sip` module is now private as its one export, `SipHasher` is
reexported in the `hash` module.
And finally, a few changes were made to the default parameters on `HashMap`.
* The `RandomSipHasher` default type parameter was renamed to `RandomState`.
This renaming emphasizes that it is not a hasher, but rather just state to
generate hashers. It also moves away from the name "sip" as it may not always
be implemented as `SipHasher`. This type lives in the
`std::collections::hash_map` module as `#[unstable]`
* The associated `Hasher` type of `RandomState` is creatively called...
`Hasher`! This concrete structure lives next to `RandomState` as an
implemenation of the "default hashing algorithm" used for a `HashMap`. Under
the hood this is currently implemented as `SipHasher`, but it draws an
explicit interface for now and allows us to modify the implementation over
time if necessary.
There are many breaking changes outlined above, and as a result this commit is
a:
[breaking-change]
2014-12-09 14:37:23 -06:00
|
|
|
use std::hash::{Hash, SipHasher};
|
2014-05-12 12:11:46 -05:00
|
|
|
|
|
|
|
pub struct StrictVersionHashVisitor<'a> {
|
std: Stabilize the std::hash module
This commit aims to prepare the `std::hash` module for alpha by formalizing its
current interface whileholding off on adding `#[stable]` to the new APIs. The
current usage with the `HashMap` and `HashSet` types is also reconciled by
separating out composable parts of the design. The primary goal of this slight
redesign is to separate the concepts of a hasher's state from a hashing
algorithm itself.
The primary change of this commit is to separate the `Hasher` trait into a
`Hasher` and a `HashState` trait. Conceptually the old `Hasher` trait was
actually just a factory for various states, but hashing had very little control
over how these states were used. Additionally the old `Hasher` trait was
actually fairly unrelated to hashing.
This commit redesigns the existing `Hasher` trait to match what the notion of a
`Hasher` normally implies with the following definition:
trait Hasher {
type Output;
fn reset(&mut self);
fn finish(&self) -> Output;
}
This `Hasher` trait emphasizes that hashing algorithms may produce outputs other
than a `u64`, so the output type is made generic. Other than that, however, very
little is assumed about a particular hasher. It is left up to implementors to
provide specific methods or trait implementations to feed data into a hasher.
The corresponding `Hash` trait becomes:
trait Hash<H: Hasher> {
fn hash(&self, &mut H);
}
The old default of `SipState` was removed from this trait as it's not something
that we're willing to stabilize until the end of time, but the type parameter is
always required to implement `Hasher`. Note that the type parameter `H` remains
on the trait to enable multidispatch for specialization of hashing for
particular hashers.
Note that `Writer` is not mentioned in either of `Hash` or `Hasher`, it is
simply used as part `derive` and the implementations for all primitive types.
With these definitions, the old `Hasher` trait is realized as a new `HashState`
trait in the `collections::hash_state` module as an unstable addition for
now. The current definition looks like:
trait HashState {
type Hasher: Hasher;
fn hasher(&self) -> Hasher;
}
The purpose of this trait is to emphasize that the one piece of functionality
for implementors is that new instances of `Hasher` can be created. This
conceptually represents the two keys from which more instances of a
`SipHasher` can be created, and a `HashState` is what's stored in a
`HashMap`, not a `Hasher`.
Implementors of custom hash algorithms should implement the `Hasher` trait, and
only hash algorithms intended for use in hash maps need to implement or worry
about the `HashState` trait.
The entire module and `HashState` infrastructure remains `#[unstable]` due to it
being recently redesigned, but some other stability decision made for the
`std::hash` module are:
* The `Writer` trait remains `#[experimental]` as it's intended to be replaced
with an `io::Writer` (more details soon).
* The top-level `hash` function is `#[unstable]` as it is intended to be generic
over the hashing algorithm instead of hardwired to `SipHasher`
* The inner `sip` module is now private as its one export, `SipHasher` is
reexported in the `hash` module.
And finally, a few changes were made to the default parameters on `HashMap`.
* The `RandomSipHasher` default type parameter was renamed to `RandomState`.
This renaming emphasizes that it is not a hasher, but rather just state to
generate hashers. It also moves away from the name "sip" as it may not always
be implemented as `SipHasher`. This type lives in the
`std::collections::hash_map` module as `#[unstable]`
* The associated `Hasher` type of `RandomState` is creatively called...
`Hasher`! This concrete structure lives next to `RandomState` as an
implemenation of the "default hashing algorithm" used for a `HashMap`. Under
the hood this is currently implemented as `SipHasher`, but it draws an
explicit interface for now and allows us to modify the implementation over
time if necessary.
There are many breaking changes outlined above, and as a result this commit is
a:
[breaking-change]
2014-12-09 14:37:23 -06:00
|
|
|
pub st: &'a mut SipHasher,
|
2014-05-12 12:11:46 -05:00
|
|
|
}
|
|
|
|
|
std: Stabilize the std::hash module
This commit aims to prepare the `std::hash` module for alpha by formalizing its
current interface whileholding off on adding `#[stable]` to the new APIs. The
current usage with the `HashMap` and `HashSet` types is also reconciled by
separating out composable parts of the design. The primary goal of this slight
redesign is to separate the concepts of a hasher's state from a hashing
algorithm itself.
The primary change of this commit is to separate the `Hasher` trait into a
`Hasher` and a `HashState` trait. Conceptually the old `Hasher` trait was
actually just a factory for various states, but hashing had very little control
over how these states were used. Additionally the old `Hasher` trait was
actually fairly unrelated to hashing.
This commit redesigns the existing `Hasher` trait to match what the notion of a
`Hasher` normally implies with the following definition:
trait Hasher {
type Output;
fn reset(&mut self);
fn finish(&self) -> Output;
}
This `Hasher` trait emphasizes that hashing algorithms may produce outputs other
than a `u64`, so the output type is made generic. Other than that, however, very
little is assumed about a particular hasher. It is left up to implementors to
provide specific methods or trait implementations to feed data into a hasher.
The corresponding `Hash` trait becomes:
trait Hash<H: Hasher> {
fn hash(&self, &mut H);
}
The old default of `SipState` was removed from this trait as it's not something
that we're willing to stabilize until the end of time, but the type parameter is
always required to implement `Hasher`. Note that the type parameter `H` remains
on the trait to enable multidispatch for specialization of hashing for
particular hashers.
Note that `Writer` is not mentioned in either of `Hash` or `Hasher`, it is
simply used as part `derive` and the implementations for all primitive types.
With these definitions, the old `Hasher` trait is realized as a new `HashState`
trait in the `collections::hash_state` module as an unstable addition for
now. The current definition looks like:
trait HashState {
type Hasher: Hasher;
fn hasher(&self) -> Hasher;
}
The purpose of this trait is to emphasize that the one piece of functionality
for implementors is that new instances of `Hasher` can be created. This
conceptually represents the two keys from which more instances of a
`SipHasher` can be created, and a `HashState` is what's stored in a
`HashMap`, not a `Hasher`.
Implementors of custom hash algorithms should implement the `Hasher` trait, and
only hash algorithms intended for use in hash maps need to implement or worry
about the `HashState` trait.
The entire module and `HashState` infrastructure remains `#[unstable]` due to it
being recently redesigned, but some other stability decision made for the
`std::hash` module are:
* The `Writer` trait remains `#[experimental]` as it's intended to be replaced
with an `io::Writer` (more details soon).
* The top-level `hash` function is `#[unstable]` as it is intended to be generic
over the hashing algorithm instead of hardwired to `SipHasher`
* The inner `sip` module is now private as its one export, `SipHasher` is
reexported in the `hash` module.
And finally, a few changes were made to the default parameters on `HashMap`.
* The `RandomSipHasher` default type parameter was renamed to `RandomState`.
This renaming emphasizes that it is not a hasher, but rather just state to
generate hashers. It also moves away from the name "sip" as it may not always
be implemented as `SipHasher`. This type lives in the
`std::collections::hash_map` module as `#[unstable]`
* The associated `Hasher` type of `RandomState` is creatively called...
`Hasher`! This concrete structure lives next to `RandomState` as an
implemenation of the "default hashing algorithm" used for a `HashMap`. Under
the hood this is currently implemented as `SipHasher`, but it draws an
explicit interface for now and allows us to modify the implementation over
time if necessary.
There are many breaking changes outlined above, and as a result this commit is
a:
[breaking-change]
2014-12-09 14:37:23 -06:00
|
|
|
pub fn make<'a>(st: &'a mut SipHasher) -> StrictVersionHashVisitor<'a> {
|
2014-05-12 12:11:46 -05:00
|
|
|
StrictVersionHashVisitor { st: st }
|
|
|
|
}
|
|
|
|
|
2015-01-12 04:02:38 -06:00
|
|
|
// To off-load the bulk of the hash-computation on #[derive(Hash)],
|
2014-05-12 12:11:46 -05:00
|
|
|
// we define a set of enums corresponding to the content that our
|
|
|
|
// crate visitor will encounter as it traverses the ast.
|
|
|
|
//
|
|
|
|
// The important invariant is that all of the Saw*Component enums
|
|
|
|
// do not carry any Spans, Names, or Idents.
|
|
|
|
//
|
|
|
|
// Not carrying any Names/Idents is the important fix for problem
|
|
|
|
// noted on PR #13948: using the ident.name as the basis for a
|
|
|
|
// hash leads to unstable SVH, because ident.name is just an index
|
|
|
|
// into intern table (i.e. essentially a random address), not
|
|
|
|
// computed from the name content.
|
|
|
|
//
|
|
|
|
// With the below enums, the SVH computation is not sensitive to
|
|
|
|
// artifacts of how rustc was invoked nor of how the source code
|
|
|
|
// was laid out. (Or at least it is *less* sensitive.)
|
|
|
|
|
|
|
|
// This enum represents the different potential bits of code the
|
|
|
|
// visitor could encounter that could affect the ABI for the crate,
|
|
|
|
// and assigns each a distinct tag to feed into the hash computation.
|
2015-01-03 21:54:18 -06:00
|
|
|
#[derive(Hash)]
|
2014-05-12 12:11:46 -05:00
|
|
|
enum SawAbiComponent<'a> {
|
|
|
|
|
|
|
|
// FIXME (#14132): should we include (some function of)
|
|
|
|
// ident.ctxt as well?
|
|
|
|
SawIdent(token::InternedString),
|
|
|
|
SawStructDef(token::InternedString),
|
|
|
|
|
|
|
|
SawLifetimeRef(token::InternedString),
|
2014-11-18 10:39:16 -06:00
|
|
|
SawLifetimeDef(token::InternedString),
|
2014-05-12 12:11:46 -05:00
|
|
|
|
|
|
|
SawMod,
|
|
|
|
SawForeignItem,
|
|
|
|
SawItem,
|
|
|
|
SawDecl,
|
|
|
|
SawTy,
|
|
|
|
SawGenerics,
|
|
|
|
SawFn,
|
|
|
|
SawTyMethod,
|
|
|
|
SawTraitMethod,
|
|
|
|
SawStructField,
|
|
|
|
SawVariant,
|
|
|
|
SawExplicitSelf,
|
|
|
|
SawPath,
|
|
|
|
SawOptLifetimeRef,
|
|
|
|
SawBlock,
|
|
|
|
SawPat,
|
|
|
|
SawLocal,
|
|
|
|
SawArm,
|
|
|
|
SawExpr(SawExprComponent<'a>),
|
|
|
|
SawStmt(SawStmtComponent),
|
|
|
|
}
|
|
|
|
|
|
|
|
/// SawExprComponent carries all of the information that we want
|
|
|
|
/// to include in the hash that *won't* be covered by the
|
|
|
|
/// subsequent recursive traversal of the expression's
|
|
|
|
/// substructure by the visitor.
|
|
|
|
///
|
|
|
|
/// We know every Expr_ variant is covered by a variant because
|
|
|
|
/// `fn saw_expr` maps each to some case below. Ensuring that
|
|
|
|
/// each variant carries an appropriate payload has to be verified
|
|
|
|
/// by hand.
|
|
|
|
///
|
|
|
|
/// (However, getting that *exactly* right is not so important
|
|
|
|
/// because the SVH is just a developer convenience; there is no
|
|
|
|
/// guarantee of collision-freedom, hash collisions are just
|
|
|
|
/// (hopefully) unlikely.)
|
2015-01-03 21:54:18 -06:00
|
|
|
#[derive(Hash)]
|
2014-05-12 12:11:46 -05:00
|
|
|
pub enum SawExprComponent<'a> {
|
|
|
|
|
|
|
|
SawExprLoop(Option<token::InternedString>),
|
|
|
|
SawExprField(token::InternedString),
|
2014-08-09 22:54:33 -05:00
|
|
|
SawExprTupField(uint),
|
2014-05-12 12:11:46 -05:00
|
|
|
SawExprBreak(Option<token::InternedString>),
|
|
|
|
SawExprAgain(Option<token::InternedString>),
|
|
|
|
|
|
|
|
SawExprBox,
|
|
|
|
SawExprVec,
|
|
|
|
SawExprCall,
|
|
|
|
SawExprMethodCall,
|
|
|
|
SawExprTup,
|
2015-01-12 21:24:37 -06:00
|
|
|
SawExprBinary(ast::BinOp_),
|
2014-05-12 12:11:46 -05:00
|
|
|
SawExprUnary(ast::UnOp),
|
|
|
|
SawExprLit(ast::Lit_),
|
|
|
|
SawExprCast,
|
|
|
|
SawExprIf,
|
|
|
|
SawExprWhile,
|
|
|
|
SawExprMatch,
|
2014-11-19 10:18:17 -06:00
|
|
|
SawExprClosure,
|
2014-05-12 12:11:46 -05:00
|
|
|
SawExprBlock,
|
|
|
|
SawExprAssign,
|
2015-01-12 21:24:37 -06:00
|
|
|
SawExprAssignOp(ast::BinOp_),
|
2014-05-12 12:11:46 -05:00
|
|
|
SawExprIndex,
|
2014-12-12 23:41:02 -06:00
|
|
|
SawExprRange,
|
2015-02-17 11:29:13 -06:00
|
|
|
SawExprPath(Option<usize>),
|
2014-05-12 12:11:46 -05:00
|
|
|
SawExprAddrOf(ast::Mutability),
|
|
|
|
SawExprRet,
|
|
|
|
SawExprInlineAsm(&'a ast::InlineAsm),
|
|
|
|
SawExprStruct,
|
|
|
|
SawExprRepeat,
|
|
|
|
SawExprParen,
|
|
|
|
}
|
|
|
|
|
|
|
|
fn saw_expr<'a>(node: &'a Expr_) -> SawExprComponent<'a> {
|
|
|
|
match *node {
|
|
|
|
ExprBox(..) => SawExprBox,
|
|
|
|
ExprVec(..) => SawExprVec,
|
|
|
|
ExprCall(..) => SawExprCall,
|
|
|
|
ExprMethodCall(..) => SawExprMethodCall,
|
|
|
|
ExprTup(..) => SawExprTup,
|
2015-01-12 21:24:37 -06:00
|
|
|
ExprBinary(op, _, _) => SawExprBinary(op.node),
|
2014-05-12 12:11:46 -05:00
|
|
|
ExprUnary(op, _) => SawExprUnary(op),
|
2014-09-07 12:09:06 -05:00
|
|
|
ExprLit(ref lit) => SawExprLit(lit.node.clone()),
|
2014-05-12 12:11:46 -05:00
|
|
|
ExprCast(..) => SawExprCast,
|
|
|
|
ExprIf(..) => SawExprIf,
|
|
|
|
ExprWhile(..) => SawExprWhile,
|
|
|
|
ExprLoop(_, id) => SawExprLoop(id.map(content)),
|
|
|
|
ExprMatch(..) => SawExprMatch,
|
2014-11-19 10:18:17 -06:00
|
|
|
ExprClosure(..) => SawExprClosure,
|
2014-05-12 12:11:46 -05:00
|
|
|
ExprBlock(..) => SawExprBlock,
|
|
|
|
ExprAssign(..) => SawExprAssign,
|
2015-01-12 21:24:37 -06:00
|
|
|
ExprAssignOp(op, _, _) => SawExprAssignOp(op.node),
|
2014-11-23 05:14:35 -06:00
|
|
|
ExprField(_, id) => SawExprField(content(id.node)),
|
|
|
|
ExprTupField(_, id) => SawExprTupField(id.node),
|
2014-05-12 12:11:46 -05:00
|
|
|
ExprIndex(..) => SawExprIndex,
|
2014-12-12 23:41:02 -06:00
|
|
|
ExprRange(..) => SawExprRange,
|
2015-02-17 11:29:13 -06:00
|
|
|
ExprPath(ref qself, _) => SawExprPath(qself.as_ref().map(|q| q.position)),
|
2014-05-12 12:11:46 -05:00
|
|
|
ExprAddrOf(m, _) => SawExprAddrOf(m),
|
|
|
|
ExprBreak(id) => SawExprBreak(id.map(content)),
|
|
|
|
ExprAgain(id) => SawExprAgain(id.map(content)),
|
|
|
|
ExprRet(..) => SawExprRet,
|
|
|
|
ExprInlineAsm(ref asm) => SawExprInlineAsm(asm),
|
|
|
|
ExprStruct(..) => SawExprStruct,
|
|
|
|
ExprRepeat(..) => SawExprRepeat,
|
|
|
|
ExprParen(..) => SawExprParen,
|
|
|
|
|
|
|
|
// just syntactic artifacts, expanded away by time of SVH.
|
2015-01-08 17:04:26 -06:00
|
|
|
ExprForLoop(..) => unreachable!(),
|
2014-08-24 21:08:48 -05:00
|
|
|
ExprIfLet(..) => unreachable!(),
|
2014-10-02 23:41:24 -05:00
|
|
|
ExprWhileLet(..) => unreachable!(),
|
2014-05-12 12:11:46 -05:00
|
|
|
ExprMac(..) => unreachable!(),
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/// SawStmtComponent is analogous to SawExprComponent, but for statements.
|
2015-01-03 21:54:18 -06:00
|
|
|
#[derive(Hash)]
|
2014-05-12 12:11:46 -05:00
|
|
|
pub enum SawStmtComponent {
|
|
|
|
SawStmtDecl,
|
|
|
|
SawStmtExpr,
|
|
|
|
SawStmtSemi,
|
|
|
|
}
|
|
|
|
|
|
|
|
fn saw_stmt(node: &Stmt_) -> SawStmtComponent {
|
|
|
|
match *node {
|
|
|
|
StmtDecl(..) => SawStmtDecl,
|
|
|
|
StmtExpr(..) => SawStmtExpr,
|
|
|
|
StmtSemi(..) => SawStmtSemi,
|
|
|
|
StmtMac(..) => unreachable!(),
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// Ad-hoc overloading between Ident and Name to their intern table lookups.
|
|
|
|
trait InternKey { fn get_content(self) -> token::InternedString; }
|
|
|
|
impl InternKey for Ident {
|
|
|
|
fn get_content(self) -> token::InternedString { token::get_ident(self) }
|
|
|
|
}
|
|
|
|
impl InternKey for Name {
|
|
|
|
fn get_content(self) -> token::InternedString { token::get_name(self) }
|
|
|
|
}
|
|
|
|
fn content<K:InternKey>(k: K) -> token::InternedString { k.get_content() }
|
|
|
|
|
2014-09-09 17:54:36 -05:00
|
|
|
impl<'a, 'v> Visitor<'v> for StrictVersionHashVisitor<'a> {
|
2014-05-12 12:11:46 -05:00
|
|
|
|
2015-01-02 15:39:05 -06:00
|
|
|
fn visit_mac(&mut self, mac: &Mac) {
|
2014-05-12 12:11:46 -05:00
|
|
|
// macro invocations, namely macro_rules definitions,
|
|
|
|
// *can* appear as items, even in the expanded crate AST.
|
|
|
|
|
2015-02-20 13:08:14 -06:00
|
|
|
if ¯o_name(mac)[..] == "macro_rules" {
|
2014-05-12 12:11:46 -05:00
|
|
|
// Pretty-printing definition to a string strips out
|
|
|
|
// surface artifacts (currently), such as the span
|
|
|
|
// information, yielding a content-based hash.
|
|
|
|
|
|
|
|
// FIXME (#14132): building temporary string is
|
|
|
|
// expensive; a direct content-based hash on token
|
|
|
|
// trees might be faster. Implementing this is far
|
|
|
|
// easier in short term.
|
2014-11-14 11:18:10 -06:00
|
|
|
let macro_defn_as_string = pprust::to_string(|pp_state| {
|
2015-01-02 15:39:05 -06:00
|
|
|
pp_state.print_mac(mac, token::Paren)
|
2014-11-14 11:18:10 -06:00
|
|
|
});
|
2014-05-12 12:11:46 -05:00
|
|
|
macro_defn_as_string.hash(self.st);
|
|
|
|
} else {
|
|
|
|
// It is not possible to observe any kind of macro
|
|
|
|
// invocation at this stage except `macro_rules!`.
|
2014-10-09 14:17:22 -05:00
|
|
|
panic!("reached macro somehow: {}",
|
2014-11-14 11:18:10 -06:00
|
|
|
pprust::to_string(|pp_state| {
|
2015-01-02 15:39:05 -06:00
|
|
|
pp_state.print_mac(mac, token::Paren)
|
2014-11-14 11:18:10 -06:00
|
|
|
}));
|
2014-05-12 12:11:46 -05:00
|
|
|
}
|
|
|
|
|
2015-01-02 15:39:05 -06:00
|
|
|
visit::walk_mac(self, mac);
|
2014-05-12 12:11:46 -05:00
|
|
|
|
2015-01-02 15:39:05 -06:00
|
|
|
fn macro_name(mac: &Mac) -> token::InternedString {
|
|
|
|
match &mac.node {
|
2014-05-12 12:11:46 -05:00
|
|
|
&MacInvocTT(ref path, ref _tts, ref _stx_ctxt) => {
|
2015-02-20 13:08:14 -06:00
|
|
|
let s = &path.segments;
|
2014-05-12 12:11:46 -05:00
|
|
|
assert_eq!(s.len(), 1);
|
|
|
|
content(s[0].identifier)
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
fn visit_struct_def(&mut self, s: &StructDef, ident: Ident,
|
2014-09-12 05:10:30 -05:00
|
|
|
g: &Generics, _: NodeId) {
|
2014-05-12 12:11:46 -05:00
|
|
|
SawStructDef(content(ident)).hash(self.st);
|
2014-09-12 05:10:30 -05:00
|
|
|
visit::walk_generics(self, g);
|
|
|
|
visit::walk_struct_def(self, s)
|
2014-05-12 12:11:46 -05:00
|
|
|
}
|
|
|
|
|
2014-09-12 05:10:30 -05:00
|
|
|
fn visit_variant(&mut self, v: &Variant, g: &Generics) {
|
2014-05-12 12:11:46 -05:00
|
|
|
SawVariant.hash(self.st);
|
|
|
|
// walk_variant does not call walk_generics, so do it here.
|
2014-09-12 05:10:30 -05:00
|
|
|
visit::walk_generics(self, g);
|
|
|
|
visit::walk_variant(self, v, g)
|
2014-05-12 12:11:46 -05:00
|
|
|
}
|
|
|
|
|
2014-09-12 05:10:30 -05:00
|
|
|
fn visit_opt_lifetime_ref(&mut self, _: Span, l: &Option<Lifetime>) {
|
2014-05-12 12:11:46 -05:00
|
|
|
SawOptLifetimeRef.hash(self.st);
|
|
|
|
// (This is a strange method in the visitor trait, in that
|
|
|
|
// it does not expose a walk function to do the subroutine
|
|
|
|
// calls.)
|
|
|
|
match *l {
|
2014-09-12 05:10:30 -05:00
|
|
|
Some(ref l) => self.visit_lifetime_ref(l),
|
2014-05-12 12:11:46 -05:00
|
|
|
None => ()
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// All of the remaining methods just record (in the hash
|
std: Stabilize the std::hash module
This commit aims to prepare the `std::hash` module for alpha by formalizing its
current interface whileholding off on adding `#[stable]` to the new APIs. The
current usage with the `HashMap` and `HashSet` types is also reconciled by
separating out composable parts of the design. The primary goal of this slight
redesign is to separate the concepts of a hasher's state from a hashing
algorithm itself.
The primary change of this commit is to separate the `Hasher` trait into a
`Hasher` and a `HashState` trait. Conceptually the old `Hasher` trait was
actually just a factory for various states, but hashing had very little control
over how these states were used. Additionally the old `Hasher` trait was
actually fairly unrelated to hashing.
This commit redesigns the existing `Hasher` trait to match what the notion of a
`Hasher` normally implies with the following definition:
trait Hasher {
type Output;
fn reset(&mut self);
fn finish(&self) -> Output;
}
This `Hasher` trait emphasizes that hashing algorithms may produce outputs other
than a `u64`, so the output type is made generic. Other than that, however, very
little is assumed about a particular hasher. It is left up to implementors to
provide specific methods or trait implementations to feed data into a hasher.
The corresponding `Hash` trait becomes:
trait Hash<H: Hasher> {
fn hash(&self, &mut H);
}
The old default of `SipState` was removed from this trait as it's not something
that we're willing to stabilize until the end of time, but the type parameter is
always required to implement `Hasher`. Note that the type parameter `H` remains
on the trait to enable multidispatch for specialization of hashing for
particular hashers.
Note that `Writer` is not mentioned in either of `Hash` or `Hasher`, it is
simply used as part `derive` and the implementations for all primitive types.
With these definitions, the old `Hasher` trait is realized as a new `HashState`
trait in the `collections::hash_state` module as an unstable addition for
now. The current definition looks like:
trait HashState {
type Hasher: Hasher;
fn hasher(&self) -> Hasher;
}
The purpose of this trait is to emphasize that the one piece of functionality
for implementors is that new instances of `Hasher` can be created. This
conceptually represents the two keys from which more instances of a
`SipHasher` can be created, and a `HashState` is what's stored in a
`HashMap`, not a `Hasher`.
Implementors of custom hash algorithms should implement the `Hasher` trait, and
only hash algorithms intended for use in hash maps need to implement or worry
about the `HashState` trait.
The entire module and `HashState` infrastructure remains `#[unstable]` due to it
being recently redesigned, but some other stability decision made for the
`std::hash` module are:
* The `Writer` trait remains `#[experimental]` as it's intended to be replaced
with an `io::Writer` (more details soon).
* The top-level `hash` function is `#[unstable]` as it is intended to be generic
over the hashing algorithm instead of hardwired to `SipHasher`
* The inner `sip` module is now private as its one export, `SipHasher` is
reexported in the `hash` module.
And finally, a few changes were made to the default parameters on `HashMap`.
* The `RandomSipHasher` default type parameter was renamed to `RandomState`.
This renaming emphasizes that it is not a hasher, but rather just state to
generate hashers. It also moves away from the name "sip" as it may not always
be implemented as `SipHasher`. This type lives in the
`std::collections::hash_map` module as `#[unstable]`
* The associated `Hasher` type of `RandomState` is creatively called...
`Hasher`! This concrete structure lives next to `RandomState` as an
implemenation of the "default hashing algorithm" used for a `HashMap`. Under
the hood this is currently implemented as `SipHasher`, but it draws an
explicit interface for now and allows us to modify the implementation over
time if necessary.
There are many breaking changes outlined above, and as a result this commit is
a:
[breaking-change]
2014-12-09 14:37:23 -06:00
|
|
|
// SipHasher) that the visitor saw that particular variant
|
2014-05-12 12:11:46 -05:00
|
|
|
// (with its payload), and continue walking as the default
|
|
|
|
// visitor would.
|
|
|
|
//
|
|
|
|
// Some of the implementations have some notes as to how one
|
|
|
|
// might try to make their SVH computation less discerning
|
|
|
|
// (e.g. by incorporating reachability analysis). But
|
|
|
|
// currently all of their implementations are uniform and
|
|
|
|
// uninteresting.
|
|
|
|
//
|
|
|
|
// (If you edit a method such that it deviates from the
|
|
|
|
// pattern, please move that method up above this comment.)
|
|
|
|
|
2014-09-12 05:10:30 -05:00
|
|
|
fn visit_ident(&mut self, _: Span, ident: Ident) {
|
2014-05-12 12:11:46 -05:00
|
|
|
SawIdent(content(ident)).hash(self.st);
|
|
|
|
}
|
|
|
|
|
2014-09-12 05:10:30 -05:00
|
|
|
fn visit_lifetime_ref(&mut self, l: &Lifetime) {
|
2014-05-12 12:11:46 -05:00
|
|
|
SawLifetimeRef(content(l.name)).hash(self.st);
|
|
|
|
}
|
|
|
|
|
2014-11-18 10:39:16 -06:00
|
|
|
fn visit_lifetime_def(&mut self, l: &LifetimeDef) {
|
|
|
|
SawLifetimeDef(content(l.lifetime.name)).hash(self.st);
|
2014-05-12 12:11:46 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
// We do recursively walk the bodies of functions/methods
|
|
|
|
// (rather than omitting their bodies from the hash) since
|
|
|
|
// monomorphization and cross-crate inlining generally implies
|
|
|
|
// that a change to a crate body will require downstream
|
|
|
|
// crates to be recompiled.
|
2014-09-12 05:10:30 -05:00
|
|
|
fn visit_expr(&mut self, ex: &Expr) {
|
|
|
|
SawExpr(saw_expr(&ex.node)).hash(self.st); visit::walk_expr(self, ex)
|
2014-05-12 12:11:46 -05:00
|
|
|
}
|
|
|
|
|
2014-09-12 05:10:30 -05:00
|
|
|
fn visit_stmt(&mut self, s: &Stmt) {
|
|
|
|
SawStmt(saw_stmt(&s.node)).hash(self.st); visit::walk_stmt(self, s)
|
2014-05-12 12:11:46 -05:00
|
|
|
}
|
|
|
|
|
2014-09-12 05:10:30 -05:00
|
|
|
fn visit_foreign_item(&mut self, i: &ForeignItem) {
|
2014-05-12 12:11:46 -05:00
|
|
|
// FIXME (#14132) ideally we would incorporate privacy (or
|
|
|
|
// perhaps reachability) somewhere here, so foreign items
|
|
|
|
// that do not leak into downstream crates would not be
|
|
|
|
// part of the ABI.
|
2014-09-12 05:10:30 -05:00
|
|
|
SawForeignItem.hash(self.st); visit::walk_foreign_item(self, i)
|
2014-05-12 12:11:46 -05:00
|
|
|
}
|
|
|
|
|
2014-09-12 05:10:30 -05:00
|
|
|
fn visit_item(&mut self, i: &Item) {
|
2014-05-12 12:11:46 -05:00
|
|
|
// FIXME (#14132) ideally would incorporate reachability
|
|
|
|
// analysis somewhere here, so items that never leak into
|
|
|
|
// downstream crates (e.g. via monomorphisation or
|
|
|
|
// inlining) would not be part of the ABI.
|
2014-09-12 05:10:30 -05:00
|
|
|
SawItem.hash(self.st); visit::walk_item(self, i)
|
2014-05-12 12:11:46 -05:00
|
|
|
}
|
|
|
|
|
2014-09-12 05:10:30 -05:00
|
|
|
fn visit_mod(&mut self, m: &Mod, _s: Span, _n: NodeId) {
|
|
|
|
SawMod.hash(self.st); visit::walk_mod(self, m)
|
2014-05-12 12:11:46 -05:00
|
|
|
}
|
|
|
|
|
2014-09-12 05:10:30 -05:00
|
|
|
fn visit_decl(&mut self, d: &Decl) {
|
|
|
|
SawDecl.hash(self.st); visit::walk_decl(self, d)
|
2014-05-12 12:11:46 -05:00
|
|
|
}
|
|
|
|
|
2014-09-12 05:10:30 -05:00
|
|
|
fn visit_ty(&mut self, t: &Ty) {
|
|
|
|
SawTy.hash(self.st); visit::walk_ty(self, t)
|
2014-05-12 12:11:46 -05:00
|
|
|
}
|
|
|
|
|
2014-09-12 05:10:30 -05:00
|
|
|
fn visit_generics(&mut self, g: &Generics) {
|
|
|
|
SawGenerics.hash(self.st); visit::walk_generics(self, g)
|
2014-05-12 12:11:46 -05:00
|
|
|
}
|
|
|
|
|
2014-09-09 17:54:36 -05:00
|
|
|
fn visit_fn(&mut self, fk: FnKind<'v>, fd: &'v FnDecl,
|
|
|
|
b: &'v Block, s: Span, _: NodeId) {
|
2014-09-12 05:10:30 -05:00
|
|
|
SawFn.hash(self.st); visit::walk_fn(self, fk, fd, b, s)
|
2014-05-12 12:11:46 -05:00
|
|
|
}
|
|
|
|
|
2014-09-12 05:10:30 -05:00
|
|
|
fn visit_ty_method(&mut self, t: &TypeMethod) {
|
|
|
|
SawTyMethod.hash(self.st); visit::walk_ty_method(self, t)
|
2014-05-12 12:11:46 -05:00
|
|
|
}
|
|
|
|
|
2014-09-12 05:10:30 -05:00
|
|
|
fn visit_trait_item(&mut self, t: &TraitItem) {
|
|
|
|
SawTraitMethod.hash(self.st); visit::walk_trait_item(self, t)
|
2014-05-12 12:11:46 -05:00
|
|
|
}
|
|
|
|
|
2014-09-12 05:10:30 -05:00
|
|
|
fn visit_struct_field(&mut self, s: &StructField) {
|
|
|
|
SawStructField.hash(self.st); visit::walk_struct_field(self, s)
|
2014-05-12 12:11:46 -05:00
|
|
|
}
|
|
|
|
|
2014-09-12 05:10:30 -05:00
|
|
|
fn visit_explicit_self(&mut self, es: &ExplicitSelf) {
|
|
|
|
SawExplicitSelf.hash(self.st); visit::walk_explicit_self(self, es)
|
2014-05-12 12:11:46 -05:00
|
|
|
}
|
|
|
|
|
2014-09-12 05:10:30 -05:00
|
|
|
fn visit_path(&mut self, path: &Path, _: ast::NodeId) {
|
|
|
|
SawPath.hash(self.st); visit::walk_path(self, path)
|
2014-05-12 12:11:46 -05:00
|
|
|
}
|
|
|
|
|
2014-09-12 05:10:30 -05:00
|
|
|
fn visit_block(&mut self, b: &Block) {
|
|
|
|
SawBlock.hash(self.st); visit::walk_block(self, b)
|
2014-05-12 12:11:46 -05:00
|
|
|
}
|
|
|
|
|
2014-09-12 05:10:30 -05:00
|
|
|
fn visit_pat(&mut self, p: &Pat) {
|
|
|
|
SawPat.hash(self.st); visit::walk_pat(self, p)
|
2014-05-12 12:11:46 -05:00
|
|
|
}
|
|
|
|
|
2014-09-12 05:10:30 -05:00
|
|
|
fn visit_local(&mut self, l: &Local) {
|
|
|
|
SawLocal.hash(self.st); visit::walk_local(self, l)
|
2014-05-12 12:11:46 -05:00
|
|
|
}
|
|
|
|
|
2014-09-12 05:10:30 -05:00
|
|
|
fn visit_arm(&mut self, a: &Arm) {
|
|
|
|
SawArm.hash(self.st); visit::walk_arm(self, a)
|
2014-05-12 12:11:46 -05:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|