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.
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
auto merge of #11114 : klutzy/rust/a, r=cmr
auto merge of #11082 : brson/rust/noat, r=alexcrichton