Several fixes for DragonFly (rebase)
Detect type inference failure when auto-dereferencing a pointer

check::autoderef() returns a ty_err when it fails to infer the type.
probe::probe() should respect this failure and fail together to prevent
further corruption.

Call stack: check::check_method_call() -> method::lookup() ->
            probe::probe() + confirm::confirm()

Fixes #19692.
Fixes #19583.
Fixes #19297.
load_self() needs to be public
Use type-alignment-sized integer for discriminant types

The previous behaviour of using the smallest type possible caused LLVM
to treat padding too conservatively, causing poor codegen. This commit
changes the behaviour to use an type-alignment-sized integer as the
discriminant. This keeps types the same size, but helps LLVM understand
the data structure a little better, resulting in better codegen.
Add enum size cases to type-sizes test
Make alignment-forcing case work the same on 64 and 32-bit platforms
Rename include_bin! to include_bytes!

According to [RFC 344][], methods that return `&[u8]` should have names
ending in `bytes`. Though `include_bin!` is a macro not a method, it
seems reasonable to follow the convention anyway.

We keep the old name around for now, but trigger a deprecation warning
when it is used.

[RFC 344]: https://github.com/rust-lang/rfcs/blob/master/text/0344-conventions-galore.md

[breaking-change]
rustc_typeck: don't expect rvalues to have unsized types.
Rename and namespace `FPCategory`

Rename `FPCategory` to `FpCategory` and `Fp* to `*` in order to adhere to the
naming convention

This is a [breaking-change].

Existing code like this:
```
use std::num::{FPCategory, FPNaN};
```
should be adjusted to this:
```
use std::num::FpCategory as Fp
```

In the following code you can use the constants `Fp::Nan`, `Fp::Normal`, etc.
auto merge of #20083 : eddyb/rust/fix-expectation, r=nikomatsakis

This fixes a few corner cases with expected type propagation, e.g.:
```rust
fn take_int_slice(_: &[int]) {}
take_int_slice(&if 1 < 0 { [ 0, 1 ] } else { [ 0, 1 ] });
```
```rust
<anon>:2:28: 2:36 error: mismatched types: expected `[int]`, found `[int, ..2]`
<anon>:2 take_int_slice(&if 1 < 0 { [ 0, 1 ] } else { [ 0, 1 ] });
                                    ^~~~~~~~
<anon>:2:46: 2:54 error: mismatched types: expected `[int]`, found `[int, ..2]`
<anon>:2 take_int_slice(&if 1 < 0 { [ 0, 1 ] } else { [ 0, 1 ] });
                                                      ^~~~~~~~
```
Right now we unpack the expected `&[int]` and pass down `[int]`, forcing
rvalue expressions to take unsized types, which causes mismatch errors.
Instead, I replaced that expectation with a weaker hint, for the unsized
cases - a hint is still required to infer the integer literals' types, above.

Fixes #20169.
Add structs for ranges to core::ops.
Add lang items for ranges.
Add syntax for ranges
Type checking and trans for ranges
Tests
Review changes
auto merge of #19758 : tbu-/rust/pr_fp_name, r=alexcrichton

This is a [breaking-change].
auto merge of #19858 : nick29581/rust/ranges, r=aturon

Closes #19794

r? @aturon for the first patch
r? @nikomatsakis for the rest
auto merge of #20060 : Aatch/rust/enum-repr, r=alexcrichton

The previous behaviour of using the smallest type possible caused LLVM
to treat padding too conservatively, causing poor codegen. This commit
changes the behaviour to use an alignment-sized integer as the
discriminant. This keeps types the same size, but helps LLVM understand
the data structure a little better, resulting in better codegen.
rustdoc: render `for<>` on old closure lifetimes