rust/src/libstd/hash, branch try

std: Recreate a `collections` module

2014-06-05T20:55:10+00:00

As with the previous commit with `librand`, this commit shuffles around some `collections` code. The new state of the world is similar to that of librand: * The libcollections crate now only depends on libcore and liballoc. * The standard library has a new module, `std::collections`. All functionality of libcollections is reexported through this module. I would like to stress that this change is purely cosmetic. There are very few alterations to these primitives. There are a number of notable points about the new organization: * std::{str, slice, string, vec} all moved to libcollections. There is no reason that these primitives shouldn't be necessarily usable in a freestanding context that has allocation. These are all reexported in their usual places in the standard library. * The `hashmap`, and transitively the `lru_cache`, modules no longer reside in `libcollections`, but rather in libstd. The reason for this is because the `HashMap::new` contructor requires access to the OSRng for initially seeding the hash map. Beyond this requirement, there is no reason that the hashmap could not move to libcollections. I do, however, have a plan to move the hash map to the collections module. The `HashMap::new` function could be altered to require that the `H` hasher parameter ascribe to the `Default` trait, allowing the entire `hashmap` module to live in libcollections. The key idea would be that the default hasher would be different in libstd. Something along the lines of: // src/libstd/collections/mod.rs pub type HashMap = core_collections::HashMap; This is not possible today because you cannot invoke static methods through type aliases. If we modified the compiler, however, to allow invocation of static methods through type aliases, then this type definition would essentially be switching the default hasher from `SipHasher` in libcollections to a libstd-defined `RandomizedSipHasher` type. This type's `Default` implementation would randomly seed the `SipHasher` instance, and otherwise perform the same as `SipHasher`. This future state doesn't seem incredibly far off, but until that time comes, the hashmap module will live in libstd to not compromise on functionality. * In preparation for the hashmap moving to libcollections, the `hash` module has moved from libstd to libcollections. A previously snapshotted commit enables a distinct `Writer` trait to live in the `hash` module which `Hash` implementations are now parameterized over. Due to using a custom trait, the `SipHasher` implementation has lost its specialized methods for writing integers. These can be re-added backwards-compatibly in the future via default methods if necessary, but the FNV hashing should satisfy much of the need for speedier hashing. A list of breaking changes: * HashMap::{get, get_mut} no longer fails with the key formatted into the error message with `{:?}`, instead, a generic message is printed. With backtraces, it should still be not-too-hard to track down errors. * The HashMap, HashSet, and LruCache types are now available through std::collections instead of the collections crate. * Manual implementations of hash should be parameterized over `hash::Writer` instead of just `Writer`. [breaking-change]

std: Remove String's to_owned

2014-05-27T18:11:15+00:00

core: rename strbuf::StrBuf to string::String

2014-05-25T04:48:10+00:00

[breaking-change]

auto merge of #14368 : tedhorst/rust/master, r=alexcrichton

2014-05-23T21:56:24+00:00

updated hash value in reduced benchmark

2014-05-23T04:07:57+00:00

auto merge of #14314 : alexcrichton/rust/deriving-hash, r=brson

2014-05-23T01:36:22+00:00

One of the long-term goals of the libstd facade is to move the collections library underneath the standard library. This would imply that libcollections today would invert its dependency with libstd. One of the primary blockers for doing this is the HashMap collection. Of its two major dependencies, hashing and randomness, this commit is the first step in dealing with hashing. When moving the hash module beneath libstd, it must break its primary dependence on the io::Writer trait (used as the hashing state). The proposed strategy for breaking this dependence is taking a similar path as core::fmt, which is to have the hash module define its own "writer trait". This trait would be similar to std::io::Writer, except that it would not return errors and it would have fewer convenience methods. The Hash trait today has its type parameter behind a feature gate (default type parameters), so this pending change will likely break no code which hasn't opted in to the feature gate. The SipState struct will lose its implementation of io::Writer, but it will regain similar methods for dealing with writing data. This change specifically prepares for the hash migration by modifying deriving(Hash) to use the std::hash::Writer bound instead of the std::io::Writer bound. This bound is currently wired to std::io::Writer, but after a snapshot it will have no need to be wired to the io writer trait.

libstd: Remove `~str` from all `libstd` modules except `fmt` and `str`.

2014-05-22T21:42:01+00:00

std: Change hash to reexport its own Writer

2014-05-21T16:15:23+00:00

core: Remove the cast module

2014-05-11T08:13:02+00:00

This commit revisits the `cast` module in libcore and libstd, and scrutinizes all functions inside of it. The result was to remove the `cast` module entirely, folding all functionality into the `mem` module. Specifically, this is the fate of each function in the `cast` module. * transmute - This function was moved to `mem`, but it is now marked as #[unstable]. This is due to planned changes to the `transmute` function and how it can be invoked (see the #[unstable] comment). For more information, see RFC 5 and #12898 * transmute_copy - This function was moved to `mem`, with clarification that is is not an error to invoke it with T/U that are different sizes, but rather that it is strongly discouraged. This function is now #[stable] * forget - This function was moved to `mem` and marked #[stable] * bump_box_refcount - This function was removed due to the deprecation of managed boxes as well as its questionable utility. * transmute_mut - This function was previously deprecated, and removed as part of this commit. * transmute_mut_unsafe - This function doesn't serve much of a purpose when it can be achieved with an `as` in safe code, so it was removed. * transmute_lifetime - This function was removed because it is likely a strong indication that code is incorrect in the first place. * transmute_mut_lifetime - This function was removed for the same reasons as `transmute_lifetime` * copy_lifetime - This function was moved to `mem`, but it is marked `#[unstable]` now due to the likelihood of being removed in the future if it is found to not be very useful. * copy_mut_lifetime - This function was also moved to `mem`, but had the same treatment as `copy_lifetime`. * copy_lifetime_vec - This function was removed because it is not used today, and its existence is not necessary with DST (copy_lifetime will suffice). In summary, the cast module was stripped down to these functions, and then the functions were moved to the `mem` module. transmute - #[unstable] transmute_copy - #[stable] forget - #[stable] copy_lifetime - #[unstable] copy_mut_lifetime - #[unstable] [breaking-change]

core: Inherit the result module

2014-05-07T15:16:14+00:00

The unwrap()/unwrap_err() methods are temporarily removed, and will be added back in the next commit.