libstd: Change `slice_shift_char`, `shift_char`, `pop_char`, `shift_byte` and `pop_byte` to return an Option instead of failing
libstd: Add unit tests for `slice_shift_char`
libstd: Update docs for `slice_shift_char` and {shift,pop}_{char,byte}
debuginfo: Improve commandline option handling for debuginfo (fixes #12811)

The `-g` flag does not take an argument anymore while the argument to `--debuginfo` becomes mandatory. This change makes it possible again to run the compiler like this:

`rustc -g ./file.rs`

This did not work before because `./file.rs` was misinterpreted as the argument to `-g`. In order to get limited debuginfo, one now has to use `--debuginfo=1`.
Port partition method from ~[T] to Vec<T>, for use early-late lifetime code.
Alpha-rename `.ident` fields of type `Name` to `.name`.
alpha-rename .ident to .name in Lifetime, including in rustdoc.
Introduce Scope<'a> shorthand for &'a ScopeChain<'a>.
Changed lists of lifetimes in ast and ty to use Vec instead of OptVec.

There is a broader revision (that does this across the board) pending
in #12675, but that is awaiting the arrival of more data (to decide
whether to keep OptVec alive by using a non-Vec internally).

For this code, the representation of lifetime lists needs to be the
same in both ScopeChain and in the ast and ty structures.  So it
seemed cleanest to just use `vec_ng::Vec`, now that it has a cheaper
empty representation than the current `vec` code.
Add proper support for early/late distinction for lifetime bindings.
Uses newly added Vec::partition method to simplify resolve_lifetime.
auto merge of #12807 : pnkfelix/rust/fsk-issue5121-fns-with-early-lifetime-params, r=pnkfelix

Fix issue #5121: Add proper support for early/late distinction for lifetime bindings.

There are some little refactoring cleanups as separate commits; the real meat that has the actual fix is in the final commit.

The original author of the work was @nikomatsakis; I have reviewed it, revised it slightly, refactored it into these separate commits, and done some rebasing work.
auto merge of #12816 : michaelwoerister/rust/limited-debuginfo, r=alexcrichton

Fixes #12811 as described in the issue.
auto merge of #12797 : pczarn/rust/str_safety, r=huonw

Along the lines of `shift_ref` and `pop_ref`.
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.