I just had `git apply` fix most of them and then did a quick skim over the diff to fix a few cases where it did the wrong thing (mostly replacing tabs with 4 spaces, when someone's editor had them at 8 spaces).
r? @pcwalton
Sorry this is so big, and sorry the first commit is just titled 'wip'.
Some interesting bits
* [LocalServices](f9069baa70) - This is the set of runtime capabilities that *all* Rust code should expect access to, including the local heap, GC, logging, unwinding.
* [impl Reader, etc. for Option](5fbb0949a5) - Constructors like `File::open` return Option<FileStream>. This lets you write I/O code without ever unwrapping an option.
This series adds a lot of [documentation](https://github.com/brson/rust/blob/io/src/libcore/rt/io/mod.rs#L11) to `core::rt::io`.
r? @brson
Unwinding through macros now happens as a call to the trait function `FailWithCause::fail_with()`, which consumes self, allowing to use a more generic failure object in the future.
Unwinding through macros now happens as a call to the trait function `FailWithCause::fail_with()`, which consumes self, allowing to use a more generic failure object in the future.
This also reverts some changes to TLS that were leaking memory.
Conflicts:
src/libcore/rt/uv/net.rs
src/libcore/task/local_data_priv.rs
src/libcore/unstable/lang.rs
Allow a deriving instance using the generic code to short-circuit for
any non-matching enum variants (grouping them all into a _ match),
reducing the number of arms required. Use this to speed up the Eq &
TotalEq implementations.
Pulls out many of the common patterns from the Eq and Clone deriving code (and
invents a few of its own), so that deriving instances are very easy to write
for a certain class of traits. (Basically, those which don't have parameters
and where all methods only take arguments of type `&Self` and return either
`Self` or types with no parameters.)
bare function store (which is not in fact a kind of value) but rather
ty::TraitRef. Removes many uses of fail!() and other telltale signs of
type-semantic mismatch.
cc #4183 (not a fix, but related)
This naming is free now that `oldmap` has finally been removed, so this is a search-and-replace to take advantage of that. It might as well be called `HashMap` instead of being named after the specific implementation, since there's only one.
SipHash distributes keys so well that I don't think there will ever be much need to use anything but a simple hash table with open addressing. If there *is* a better way to do it, it will probably be better in all cases and can just be the default implementation.
A cuckoo-hashing implementation combining a weaker hash with SipHash could be useful, but that won't be as general purpose - you would need to write a separate fast hash function specialized for the type to really take advantage of it (like taking a page from libstdc++/libc++ and just using the integer value as the "hash"). I think a more specific naming for a truly alternative implementation like that would be fine, with the nice naming reserved for the general purpose container.
