Commit Graph

18 Commits

Author SHA1 Message Date
Alex Crichton
43bfaa4a33 Mass rename uint/int to usize/isize
Now that support has been removed, all lingering use cases are renamed.
2015-03-26 12:10:22 -07:00
Brian Anderson
8c93a79e38 rustdoc: Replace no-pretty-expanded with pretty-expanded
Now that features must be declared expanded source often does not compile.
This adds 'pretty-expanded' to a bunch of test cases that still work.
2015-03-23 14:40:26 -07:00
Tamir Duberstein
d51047ded0 Strip all leading/trailing newlines 2015-03-15 09:08:21 -07:00
Alex Crichton
f83e23ad7c std: Stabilize the hash module
This commit is an implementation of [RFC 823][rfc] which is another pass over
the `std::hash` module for stabilization. The contents of the module were not
entirely marked stable, but some portions which remained quite similar to the
previous incarnation are now marked `#[stable]`. Specifically:

[rfc]: https://github.com/rust-lang/rfcs/blob/master/text/0823-hash-simplification.md

* `std::hash` is now stable (the name)
* `Hash` is now stable
* `Hash::hash` is now stable
* `Hasher` is now stable
* `SipHasher` is now stable
* `SipHasher::new` and `new_with_keys` are now stable
* `Hasher for SipHasher` is now stable
* Many `Hash` implementations are now stable

All other portions of the `hash` module remain `#[unstable]` as they are less
commonly used and were recently redesigned.

This commit is a breaking change due to the modifications to the `std::hash` API
and more details can be found on the [RFC][rfc].

Closes #22467
[breaking-change]
2015-02-18 08:26:20 -08:00
Alex Crichton
511f0b8a3d 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]
2015-01-07 12:18:08 -08:00
Nick Cameron
30e149231c Use derive rather than deriving in tests 2015-01-02 23:05:22 +13:00
Joseph Crail
2016742e07 Fix misspelled comments for tests. 2014-08-09 22:08:36 -04:00
Piotr Jawniak
37b8ce0064 Remove duplicated test files
Even if they used to test different things in the past, they are
now identical to other files.

Closes #11496
2014-06-22 15:55:27 +02:00
Alex Crichton
748bc3ca49 std: Rename {Eq,Ord} to Partial{Eq,Ord}
This is part of the ongoing renaming of the equality traits. See #12517 for more
details. All code using Eq/Ord will temporarily need to move to Partial{Eq,Ord}
or the Total{Eq,Ord} traits. The Total traits will soon be renamed to {Eq,Ord}.

cc #12517

[breaking-change]
2014-05-30 15:52:24 -07:00
Brian Anderson
072a920503 Remove check-fast. Closes #4193, #8844, #6330, #7416 2014-04-06 15:55:43 -07:00
Erick Tryzelaar
922eb47a20 test: Use #[deriving(Hash)] in a couple tests 2014-02-24 19:52:29 -08:00
Huon Wilson
efaf4db24c Transition to new Hash, removing IterBytes and std::to_bytes. 2014-02-24 07:44:10 +11:00
Erick Tryzelaar
d223dd1e57 std: rewrite Hash to make it more generic
This patch merges IterBytes and Hash traits, which clears up the
confusion of using `#[deriving(IterBytes)]` to support hashing.
Instead, it now is much easier to use the new `#[deriving(Hash)]`
for making a type hashable with a stream hash.

Furthermore, it supports custom non-stream-based hashers, such as
if a value's hash was cached in a database.

This does not yet replace the old IterBytes-hash with this new
version.
2014-02-21 21:33:23 -08:00
Florian Hahn
f62460c1f5 Change xfail directives in compiletests to ignore, closes #11363 2014-02-11 18:23:20 +01:00
Jason Fager
da559b2b36 Replace HashUtil w/ default method on Hash 2013-08-27 21:41:10 -04:00
Erick Tryzelaar
ad5c676853 Fix warnings it tests 2013-08-17 08:42:35 -07:00
Patrick Walton
1be40be613 test: Update tests to use the new syntax. 2013-05-22 21:57:10 -07:00
Andrew Paseltiner
24efea7208 syntax: implement #[deriving] meta-attribute 2013-03-12 12:52:39 -04:00