improve clone_from_slice performance
add intmax
Add assume intrinsic

Adds an `assume` intrinsic that gets translated to llvm.assume. It is
used on a boolean expression and allows the optimizer to assume that
the expression is true.

This implements #18051.
Improve documentation of assume intrinsic.
Guide: articulate the advantages of ownership over garbage collection.

Explain the primary disadvantage of garbage collection is runtime
overhead and unpredictable pauses.  Elucidate where the name "race
condition" comes from.  Emphasize that Rust can guarantee your code is
free of race conditions and other memory errors, with no runtime
overhead.
auto merge of #17960 : mahkoh/rust/clone_from_slice, r=pcwalton

Old vs. New vs. Vec::push_all

```
test slice     ... bench:   3091942 ns/iter (+/- 54460)
test slice_new ... bench:   1800065 ns/iter (+/- 69513)
test vec       ... bench:   1804805 ns/iter (+/- 75609)
```
Fix sigaction on OS X
Add a lint for not using field pattern shorthands

Closes #17792.
auto merge of #17896 : mahkoh/rust/intmax, r=alexcrichton

Closes #17075

I don't know if this is correct. The easiest way to find out is to run the following program on all targets but I can't do it myself.
```c
#include <stdint.h>
#include <stdio.h>

int main(void)
{
	if (sizeof(intmax_t) != 8) {
		puts("ERROR");
		return 1;
	}
}
```
Print stack overflow messages for Windows, Linux and OS X

Fixes #17562
auto merge of #17813 : P1start/rust/lint-field-shorthand, r=huonw

Closes #17792.
auto merge of #16388 : Zoxc/rust/stmesg, r=alexcrichton

This installs signal handlers to print out stack overflow messages on Linux. It also ensures the main thread has a guard page.

This will catch stack overflows in external code. It's done in preparation of switching to stack probes (#16012).

I've done some simple tests with overflowing the main thread, native threads and green threads (with and without UV) on x86-64.
This might work on ARM, MIPS and x86-32.

I've been unable to run the test suite on this because of #16305.
Do not accept functions in enum patterns past resolve
Overhaul typechecking of patterns

Instead of checking patterns in a top-down fashion with a known
expected type on entry, this changes makes typeck establish
appropriate constraints between a pattern and the expression
it destructures, and lets inference compute the final types
or produce good error messages if it's impossible.
Update tests with the new error messages
auto merge of #18080 : veddan/rust/assume, r=thestinger

Adds an `assume` intrinsic that gets translated to llvm.assume. It is
used on a boolean expression and allows the optimizer to assume that
the expression is true.

This implements #18051.
auto merge of #18171 : jakub-/rust/match-typeck, r=pcwalton

Rather than doing it top-down, with a known expected type, we will now simply establish the appropriate constraints between the pattern and the expression it destructures.

Closes #8783.
Closes #10200.
auto merge of #18176 : jkleint/rust/guide-borrow-wording, r=steveklabnik

Explain the primary disadvantage of garbage collection is runtime
overhead and unpredictable pauses.  Elucidate where the name "race
condition" comes from.  Emphasize that Rust can guarantee your code is
free of race conditions and other memory errors, with no runtime
overhead.

cc @steveklabnik
libserialize: tuple-arity should be provided to `Decoder::read_tuple`

Currently `Decoder` implementations are not provided the tuple arity as
a parameter to `read_tuple`. This forces all encoder/decoder combos to
serialize the arity along with the elements. Tuple-arity is always known
statically at the decode site, because it is part of the type of the
tuple, so it could instead be provided as an argument to `read_tuple`,
as it is to `read_struct`.

The upside to this is that serialized tuples could become smaller in
encoder/decoder implementations which choose not to serialize type
(arity) information. For example, @TyOverby's
[binary-encode](https://github.com/TyOverby/binary-encode) format is
currently forced to serialize the tuple-arity along with every tuple,
despite the information being statically known at the decode site.

A downside to this change is that the tuple-arity of serialized tuples
can no longer be automatically checked during deserialization. However,
for formats which do serialize the tuple-arity, either explicitly (rbml)
or implicitly (json), this check can be added to the `read_tuple` method.

The signature of `Deserialize::read_tuple` and
`Deserialize::read_tuple_struct` are changed, and thus binary
backwards-compatibility is broken. This change does *not* force
serialization formats to change, and thus does not break decoding values
serialized prior to this change.

[breaking-change]
Tuple deserialization should not fail