Add lru_cache to libextra
Disable priv in std::comm::Port, etc

It's useful to allow users to get at the internal std::rc::comm::Port,
and other such fields, since they implement important traits like
Select.
std::libc: Remove TCHAR types
std::libc: Simplify win32/win64 type definitions
std: Fix transmute error on win64
llvm: Disable pthreads on mingw-w64 platforms
std::rt: Fix record_stack_bounds on win64
std::rt: Fix crate_map on Win64
Fix spelling of "vacuum" in one of the abort quotes.
rustdoc: pass through --cfg to rustc

Closes #10623
Set uv's custom data before uv_read_start

This is a behavioral difference in libuv between different platforms in
different situations. It turns out that libuv on windows will immediately
allocate a buffer instead of waiting for data to be ready. What this implies is
that we must have our custom data set on the handle before we call
uv_read_start.

I wish I knew of a way to test this, but this relies to being on the windows
platform *and* reading from a true TTY handle which only happens when this is
actually attached to a terminal. I have manually verified this works.

Closes #10645
std: IPv6 addresses are represented as eight groups of four HEXADECIMAL digits
Represent C-like enums with a plain LLVM integer, not a struct.

This is needed so that the FFI works as expected on platforms that don't
flatten aggregates the way the AMD64 ABI does, especially for `#[repr(C)]`.

This moves more of `type_of` into `trans::adt`, because the type might
or might not be an LLVM struct.
Fix typo in base64 test

We want a 1000 element array, not a 2 element array
auto merge of #10643 : jorendorff/rust/master, r=alexcrichton
Add [mut_]shift_ref/[mut_]pop_ref functions, which return a pointer to the first/last item in the slice and modify the slice to exclude the returned item. Useful when writing iterators over mutable references.
auto merge of #10644 : cmr/rust/rustdoc_cfg, r=alexcrichton

Closes #10623
rm #[mutable_doc]
auto merge of #10646 : alexcrichton/rust/issue-10645, r=luqmana

This is a behavioral difference in libuv between different platforms in
different situations. It turns out that libuv on windows will immediately
allocate a buffer instead of waiting for data to be ready. What this implies is
that we must have our custom data set on the handle before we call
uv_read_start.

I wish I knew of a way to test this, but this relies to being on the windows
platform *and* reading from a true TTY handle which only happens when this is
actually attached to a terminal. I have manually verified this works.

Closes #10645
Remove arms_have_move_bindings