libstd: Implement `StrBuf`, a new string buffer type like `Vec`, and
port all code over to use it.
rustc: rename ty::vstore and its variants to UpperCamelCase.
rustc: use VstoreFixed's length in crate-independent type hashes.
rustc: move mutability from ty_vec and ty_trait to VstoreSlice and RegionTraitStore.
Document the nullable pointer optimization in the FFI guide

Closes #8748
Fix tests. Add Vec<u8> conversion to StrBuf.
Register snapshots.

This is the first snap based on mingw-w64.
auto merge of #13440 : huonw/rust/strbuf, r=alexcrichton

libstd: Implement `StrBuf`, a new string buffer type like `Vec`, and port all code over to use it.

Rebased & tests-fixed version of https://github.com/mozilla/rust/pull/13269
std: Make std::comm return types consistent

There are currently a number of return values from the std::comm methods, not
all of which are necessarily completely expressive:

  Sender::try_send(t: T) -> bool
    This method currently doesn't transmit back the data `t` if the send fails
    due to the other end having disconnected. Additionally, this shares the name
    of the synchronous try_send method, but it differs in semantics in that it
    only has one failure case, not two (the buffer can never be full).

  SyncSender::try_send(t: T) -> TrySendResult<T>
    This method accurately conveys all possible information, but it uses a
    custom type to the std::comm module with no convenience methods on it.
    Additionally, if you want to inspect the result you're forced to import
    something from `std::comm`.

  SyncSender::send_opt(t: T) -> Option<T>
    This method uses Some(T) as an "error value" and None as a "success value",
    but almost all other uses of Option<T> have Some/None the other way

  Receiver::try_recv(t: T) -> TryRecvResult<T>
    Similarly to the synchronous try_send, this custom return type is lacking in
    terms of usability (no convenience methods).

With this number of drawbacks in mind, I believed it was time to re-work the
return types of these methods. The new API for the comm module is:

  Sender::send(t: T) -> ()
  Sender::send_opt(t: T) -> Result<(), T>
  SyncSender::send(t: T) -> ()
  SyncSender::send_opt(t: T) -> Result<(), T>
  SyncSender::try_send(t: T) -> Result<(), TrySendError<T>>
  Receiver::recv() -> T
  Receiver::recv_opt() -> Result<T, ()>
  Receiver::try_recv() -> Result<T, TryRecvError>

The notable changes made are:

* Sender::try_send => Sender::send_opt. This renaming brings the semantics in
  line with the SyncSender::send_opt method. An asychronous send only has one
  failure case, unlike the synchronous try_send method which has two failure
  cases (full/disconnected).

* Sender::send_opt returns the data back to the caller if the send is guaranteed
  to fail. This method previously returned `bool`, but then it was unable to
  retrieve the data if the data was guaranteed to fail to send. There is still a
  race such that when `Ok(())` is returned the data could still fail to be
  received, but that's inherent to an asynchronous channel.

* Result is now the basis of all return values. This not only adds lots of
  convenience methods to all return values for free, but it also means that you
  can inspect the return values with no extra imports (Ok/Err are in the
  prelude). Additionally, it's now self documenting when something failed or not
  because the return value has "Err" in the name.

Things I'm a little uneasy about:

* The methods send_opt and recv_opt are not returning options, but rather
  results. I felt more strongly that Option was the wrong return type than the
  _opt prefix was wrong, and I coudn't think of a much better name for these
  methods. One possible way to think about them is to read the _opt suffix as
  "optionally".

* Result<T, ()> is often better expressed as Option<T>. This is only applicable
  to the recv_opt() method, but I thought it would be more consistent for
  everything to return Result rather than one method returning an Option.

Despite my two reasons to feel uneasy, I feel much better about the consistency
in return values at this point, and I think the only real open question is if
there's a better suffix for {send,recv}_opt.

Closes #11527
std: Be sure to call pthread_attr_destroy

On some OSes (such as freebsd), pthread_attr_init allocates memory, so this is
necessary to deallocate that memory.

Closes #13420
auto merge of #13451 : cmr/rust/doc-ffi, r=brson

Closes #8748
rustc: fix the fallout from moving mutability into VstoreSlice and RegionTraitStore.
auto merge of #13453 : brson/rust/snappies, r=alexcrichton

This is the first snap based on mingw-w64.
auto merge of #13457 : alexcrichton/rust/issue-13420, r=thestinger

On some OSes (such as freebsd), pthread_attr_init allocates memory, so this is
necessary to deallocate that memory.

Closes #13420
libtest: rename `BenchHarness` to `Bencher`
Closes #12640
auto merge of #13424 : eddyb/rust/ty-mut-in-store, r=nikomatsakis

Cleans up some remnants of the old mutability system and only allows vector/trait mutability in `VstoreSlice` (`&mut [T]`) and `RegionTraitStore` (`&mut Trait`).
Add more type signatures to the docs; tweak a few of them.

Someone reading the docs won't know what the types of various things
are, so this adds them in a few meaningful places to help with
comprehension.

cc #13423.
auto merge of #13236 : liigo/rust/rename-benchharness, r=huonw

Closes #12640

based on PR #13030, rebased, and passed all tests.
auto merge of #13458 : huonw/rust/doc-signatures, r=alexcrichton

Add more type signatures to the docs; tweak a few of them.

Someone reading the docs won't know what the types of various things
are, so this adds them in a few meaningful places to help with
comprehension.

cc #13423.
Parameterize contains_nul for BytesContainer.