Explicitly write down 0.1 release date in RELEASES.txt, to confirm Rust's birthday.
Index cross-mod type definition and implementation properly in rustdoc

A structure's definition and implementation may be cross-module. If the
implementing module is parsed before defining module, the fully
qualified name of the structure won't be present for the implementation
to use when being indexed. So caches such 'orphan' implementation and
indexes it at the end of crate parsing.

Closes #10284.
auto merge of #12752 : edwardw/rust/rdoc, r=alexcrichton

A structure's definition and implementation may be cross-module. If the
implementing module is parsed before defining module, the fully
qualified name of the structure won't be present for the implementation
to use when being indexed. So caches such 'orphan' implementation and
indexes it at the end of crate parsing.

Closes #10284.
auto merge of #12748 : liigo/rust/rust-birthday, r=brson

Rust v0.1 was released on January 20, 2012:
https://mail.mozilla.org/pipermail/rust-dev/2012-January/001256.html
create a sensible comparison trait hierarchy

* `Ord` inherits from `Eq`
* `TotalOrd` inherits from `TotalEq`
* `TotalOrd` inherits from `Ord`
* `TotalEq` inherits from `Eq`

This is a partial implementation of #12517.
auto merge of #12520 : thestinger/rust/cmp, r=brson

* `Ord` inherits from `Eq`
* `TotalOrd` inherits from `TotalEq`
* `TotalOrd` inherits from `Ord`
* `TotalEq` inherits from `Eq`

This is a partial implementation of #12517.
doc: don't refer to 'char' as characters

This seems to be causing some confusion among users. Rust's char are
not 8bit characters, but 32bit UCS-4 codepoint without surrogates
(Unicode Scalar Values as per Unicode glossary).
Make the doc more explicit about it.

Signed-off-by: Luca Bruno <lucab@debian.org>
doc: uniform std::char doc-strings

Uniform and beautify doc-string for current rustdoc output.

Signed-off-by: Luca Bruno <lucab@debian.org>
doc: add two missing char methods doc-strings

XID_* property are defined in UAX #31, just reference it here.

Signed-off-by: Luca Bruno <lucab@debian.org>
libstd: Add some more functionality to Vec<T>
Removed DeepClone. Issue #12698.
librustc: Automatically change uses of `~[T]` to `Vec<T>` in rustc.
librustc: Fix up fallout from the automatic conversion.
librustdoc: Fix librustdoc for the `Vec<T>` change.
Incorporated review feedback atop pcwalton's original patches.

(Original PR was #12716; feedback was provided by thestinger and me.)
auto merge of #12768 : pnkfelix/rust/fsk-devecing, r=pnkfelix

Change `~[T]` to Vec<T> in librustc.  Rebased and amended version of PR #12716.

Original author (or perhaps I should say meta-author) was @pcwalton, as is reflected in the commits.

I clean up!  :)
auto merge of #12759 : lucab/rust/char-doc, r=alexcrichton

This is mostly a reaction to #12730. If we are going to keep calling them `char`, at least make it clear that they aren't characters but codepoint/scalar.
auto merge of #12706 : pongad/rust/issue_12698, r=brson

Fixes #12698
Performance-oriented hashtable.

Previously, rust's hashtable was totally unoptimized. It used an Option
per key-value pair, and used very naive open allocation.

The old hashtable had very high variance in lookup time. For an example,
see the 'find_nonexisting' benchmark below. This is fixed by keys in
'lucky' spots with a low probe sequence length getting their good spots
stolen by keys with long probe sequence lengths. This reduces hashtable
probe length variance, while maintaining the same mean.

Also, other optimization liberties were taken. Everything is as cache
aware as possible, and this hashtable should perform extremely well for
both large and small keys and values.

Benchmarks:

comprehensive_old_hashmap         378 ns/iter (+/- 8)
comprehensive_new_hashmap         206 ns/iter (+/- 4)
1.8x faster

old_hashmap_as_queue              238 ns/iter (+/- 8)
new_hashmap_as_queue              119 ns/iter (+/- 2)
2x faster

old_hashmap_insert                172 ns/iter (+/- 8)
new_hashmap_insert                146 ns/iter (+/- 11)
1.17x faster

old_hashmap_find_existing         50 ns/iter (+/- 12)
new_hashmap_find_existing         35 ns/iter (+/- 6)
1.43x faster

old_hashmap_find_notexisting      49 ns/iter (+/- 49)
new_hashmap_find_notexisting      34 ns/iter (+/- 4)
1.44x faster

Memory usage of old hashtable (64-bit assumed):

aligned(8+sizeof(K)+sizeof(V))/0.75 + 6 words

Memory usage of new hashtable:

(aligned(sizeof(K))
+ aligned(sizeof(V))
+ 8)/0.9 + 6.5 words

BUT accesses are much more cache friendly. In fact, if the probe
sequence length is below 8, only two cache lines worth of hashes will be
pulled into cache. This is unlike the old version which would have to
stride over the stoerd keys and values, and would be more cache
unfriendly the bigger the stored values got.

And did you notice the higher load factor? We can now reasonably get a
load factor of 0.9 with very good performance.