Make BufferedReader propagate 0-byte long reads.

Could prevent callers from catching the situation and lead to e.g early
iterator terminations (cf. `Reader::read_byte') since `None' is only to
be returned only on EOF.
Fix #10755 - ICE: `--linker=`

Trap the io_error condition so that a more informative error message is
displayed when the linker program cannot be started, such as when the
name of the linker binary is accidentally mistyped.

closes #10755
std::vec: implement a stable merge sort, deferring to insertion sort for
very small runs.

This uses a lot of unsafe code for speed, otherwise we would be having
to sort by sorting lists of indices and then do a pile of swaps to put
everything in the correct place.

Fixes #9819.
extra: remove sort in favour of the std method.

Fixes #9676.
std::vec: add a sugary .sort() method for plain Ord sorting.

This moves the custom sorting to `.sort_by`.
mk: Work around problem with run-make tests on multiple targets. #11094
mk: Remove obsolete source reformatting rules
Remove unnecessary semicolon
std: Remove some @-boxes
auto merge of #11095 : brson/rust/issue-11094, r=alexcrichton
Don't poison ARCs that are used while unwinding

Closes #11097
Remove unneccessary mut from arc
Attempt to fix the segfaulting osx bots

Upon inspecting the core dumps, they're all segfaulting at the same instruction
with the same value in a register that looks fishy. It appears to be indexing
into an array with a -1 index and then getting some weird overflow and dying.

I have attempted to fix this as part of
alexcrichton/libuv@fd5308383c575472edb2163d823dc6670bf59609,
but I am unsure of whether this is the actual cause of the problem, so I am not
going to upstream it just yet. I have a fairly high confidence that this is
indeed the problem, but I want to make sure that the bots to segfault all over
the place before upstreaming.
auto merge of #11110 : alexcrichton/rust/attempt-to-fix-osx-segfaulting, r=brson

Upon inspecting the core dumps, they're all segfaulting at the same instruction
with the same value in a register that looks fishy. It appears to be indexing
into an array with a -1 index and then getting some weird overflow and dying.

I have attempted to fix this as part of
alexcrichton/libuv@fd5308383c575472edb2163d823dc6670bf59609,
but I am unsure of whether this is the actual cause of the problem, so I am not
going to upstream it just yet. I have a fairly high confidence that this is
indeed the problem, but I want to make sure that the bots to segfault all over
the place before upstreaming.
Guarantee comm primitives are not Freeze

None of these primitives should be Freeze because sharing them in an Arc is a
very bad idea.

Closes #11039
auto merge of #10997 : cadencemarseille/rust/issue-10755-ICE-for-missing-linker, r=alexcrichton

Trap the io_error condition so that a more informative error message is
displayed when the linker program cannot be started, such as when the
name of the linker binary is accidentally mistyped.

closes #10755
std::vec: make the sorting closure use `Ordering` rather than just being
(implicitly) less_eq.
fix check-fast tests.
auto merge of #11064 : huonw/rust/vec-sort, r=alexcrichton

This uses quite a bit of unsafe code for speed and failure safety, and allocates `2*n` temporary storage.

[Performance](https://gist.github.com/huonw/5547f2478380288a28c2):

|      n |      new | priority_queue |   quick3 |
|-------:|---------:|---------------:|---------:|
|      5 |      200 |            155 |      106 |
|    100 |     6490 |           8750 |     5810 |
|  10000 |  1300000 |        1790000 |  1060000 |
| 100000 | 16700000 |       23600000 | 12700000 |
| sorted |   520000 |        1380000 | 53900000 |
|  trend |  1310000 |        1690000 |  1100000 |

(The times are in nanoseconds, having subtracted the set-up time (i.e. the `just_generate` bench target).)

I imagine that there is still significant room for improvement, particularly because both priority_queue and quick3 are doing a static call via `Ord` or `TotalOrd` for the comparisons, while this is using a (boxed) closure.

Also, this code does not `clone`, unlike `quick_sort3`; and is stable, unlike both of the others.
mk: Clean .lib files