Normalize return type when checking for E0269

Fixes #31597

Auto merge of #32266 - alexcrichton:fix-mingw-rustbuild-again, r=brson

rustbuild: Fix LLVM compile on MinGW

The LLVM change [1] in #32239 unfortunately broke the LLVM build on MinGW, so
this LLVM submodule update brings in one more fix [2] which should hopefully
remedy that.

Once this lands we should be able to immediately start gating on this to prevent
it from happening again.

[1]: https://github.com/rust-lang/llvm/commit/be89e4b5
[2]: https://github.com/rust-lang/llvm/commit/3dcd2c84

Auto merge of #32236 - alexcrichton:better-compile-intrinsics, r=arielb1

rustc: Improve compile time of platform intrinsics

This commit improves the compile time of `rustc_platform_intrinsics` from 23s to
3.6s if compiling with `-O` and from 77s to 17s if compiling with `-O -g`. The
compiled rlib size also drops from 3.1M to 1.2M.

The wins here were gained by removing the destructors associated with `Type` by
removing the internal `Box` and `Vec` indirections. These destructors meant that
a lot of landing pads and extra code were generated to manage the runtime
representations. Instead everything can basically be statically computed and
shoved into rodata, so all we need is a giant string compare to lookup what's
what.

Closes #28273

rustc: Improve compile time of platform intrinsics

This commit improves the compile time of `rustc_platform_intrinsics` from 23s to
3.6s if compiling with `-O` and from 77s to 17s if compiling with `-O -g`. The
compiled rlib size also drops from 3.1M to 1.2M.

The wins here were gained by removing the destructors associated with `Type` by
removing the internal `Box` and `Vec` indirections. These destructors meant that
a lot of landing pads and extra code were generated to manage the runtime
representations. Instead everything can basically be statically computed and
shoved into rodata, so all we need is a giant string compare to lookup what's
what.

Closes #28273

Auto merge of #31838 - aochagavia:trans, r=nrc

Refactor rustc_trans::save to allow other backends than CSV

r? @nrc

Things done:
* Moved `(.*)Data` structs to an own module, so they can be imported easily (`use data::*`).
* Created a `Dump` trait with callbacks for dumping items.
* Refactored `DumpCsvVisitor` to use an implementor of `Dump` instead of dumping as CSV. Renamed it to `DumpVisitor`.
* Created a `DumpCsv` struct that implements `Dump` and serializes items as CSV.

I tried to extract some of the logic contained in `FmtStr` and `Recorder`, such as normalization of ids (I put it in `DumpVisitor`). I think it makes sense to provide the same information to other implementors of `Dump`, instead of normalizing only for `DumpCsv`. However, there is still some logic related to spans implemented only for `DumpCsv`. I just thought it would be better to merge this as soon as possible, since there are so much changes, and fix this afterwards.

Refactor rustc_trans::save

Move rustc_trans::*Data to own module
Add new data to rustc_trans::save
Create a Dump trait implemented by structs that dump save analysis data
Split dump_csv into a DumpVisitor and a CsvDumper

rustbuild: Fix LLVM compile on MinGW

The LLVM change [1] in #32239 unfortunately broke the LLVM build on MinGW, so
this LLVM submodule update brings in one more fix [2] which should hopefully
remedy that.

Once this lands we should be able to immediately start gating on this to prevent
it from happening again.

[1]: https://github.com/rust-lang/llvm/commit/be89e4b5
[2]: https://github.com/rust-lang/llvm/commit/3dcd2c84

Auto merge of #31887 - SimonSapin:quiet-test, r=alexcrichton

Shorter output for `rustc --test` binaries.

Until now, a program created with `rustc --test` prints at least one line per test. This can be very verbose, especially with [data-driven tests](https://internals.rust-lang.org/t/test-and-external-test-harnesses/3145) when hundreds or thousands of tests is not rare.

This changes the default output to one character per test (except metrics and benchmarks results which have additional data to show):

```
     Running target/debug/wpt-75c594dc1e6e6187

running 314 tests
..............................................................................
..............................................................................
..............................................................................
..............................................................................
..
test result: ok. 314 passed; 0 failed; 0 ignored; 0 measured
```

<s>The previous behavior is available by passing `--verbose` to the test program. Maybe `cargo test --verbose` could be changed to do that?</s> **Edit:** the default is now unchanged, `-q` or `--quiet` enables the new output.

Add a test for --quiet in test harness.

Shorter output for `rustc --test` binaries.

A program created with `rustc --test` prints at least one line per test.
This can be very verbose, especially with [data-driven tests](
https://internals.rust-lang.org/t/test-and-external-test-harnesses/3145)
when hundreds or thousands of tests is not rare.

This adds a `-q` or `--quiet` option that changes the output
to one character instead of one line per test
(except metrics and benchmarks results which have additional data to
show):

```
     Running target/debug/wpt-75c594dc1e6e6187

running 314 tests
..............................................................................
..............................................................................
..............................................................................
..............................................................................
..
test result: ok. 314 passed; 0 failed; 0 ignored; 0 measured
```

This is a breaking change since the `test::TestOpts` struct
now has one more field.

Auto merge of #32251 - durka:derive-2810, r=alexcrichton

derive: clean up hygiene

derive: clean up hygiene

Fixes #2810.

Spawned from #32139.

r? @alexcrichton

Auto merge of #32250 - durka:derive-31574, r=alexcrichton

derive: use intrinsics::unreachable over unreachable!()

derive: use intrinsics::unreachable over unreachable!()

Fixes #31574.

Spawned from #32139.

r? @alexcrichton

Auto merge of #32239 - alexcrichton:fix-cross-to-freebsd, r=brson

rustbuild: Fix cross compiling to FreeBSD

This commit fixes our support for cross compiling a compiler to run on FreeBSD.
Over the weekend I managed to get a cross compiler from Linux to FreeBSD [1]
which I hope to soon use to start producing FreeBSD nightly compilers. With the
`make dist` support added in #32237 we should be able to produce standard
rustc/rust-std packages for FreeBSD through a new slave with this cross compiler.

Currently, however, we don't "Just Work" when cross compiling FreeBSD and a
number of changes were required (part of this PR). They include:

* A few build fixes were needed in LLVM. Our own branch has been rebased on the
  actual 3.8 release and I applied one extra commit [2] which contains two fixes:

  1. The LLVM CMake build system passes the `-Wl,-z,defs` flag on many
     platforms, but *not* when `CMAKE_SYSTEM_NAME` is "FreeBSD". Unfortunately
     this doesn't take into account when we're cross compiling, and as predicted
     the build will fail if `-Wl,-z,defs` is passed (see [3] for more info). To
     fix this we test `TARGET_TRIPLE` instead of the `CMAKE_SYSTEM_NAME` which
     is what we're compiling for which fixes the problem.
  2. The `PATH_MAX` constant is apparently defined in a different location than
     many other Unix systems, so a file which required this just needed some
     help to keep compiling.

* Support for compiling compiler-rt with CMake has been added to rustbuild. It
  looks like it just emulates Linux in what it compiles as it didn't seem to
  naturally produce anything else... At least the architecture is right, so
  seems good for now at least!

[1]: https://github.com/alexcrichton/port-of-rust/blob/master/prebuilt/freebsd/Dockerfile
[2]: https://github.com/rust-lang/llvm/commit/be89e4b5
[3]: https://bugs.webkit.org/show_bug.cgi?id=138420

Auto merge of #32238 - frewsxcv:compiletest, r=alexcrichton

Utilize `Option::cloned` over explicit `clone` usage.

Auto merge of #32206 - alexcrichton:fix-windows-rustbuild, r=brson

Fix Windows rustbuild

These commits fix the rustbuild Windows bots, namely:

* The 32-bit build of LLVM was failing because libraries weren't being linked. This was in turn caused by the build script for `rustc_llvm` erroneously detecting that it was cross compiling when it actually wasn't.
* Tools of the build were compiled against the wrong libraries, so running them would fail on Windows as rpath didn't exist and `PATH` was wrong.
* Some linkchecker fixes for Windows paths had to be applied as well.

Auto merge of #30652 - aturon:specialization, r=nikomatsakis

Implement RFC 1210: impl specialization

This PR implements [impl specialization](https://github.com/rust-lang/rfcs/pull/1210),
carefully following the proposal laid out in the RFC.

The implementation covers the bulk of the RFC. The remaining gaps I know of are:

- no checking for lifetime-dependent specialization (a soundness hole);
- no `default impl` yet;
- no support for `default` with associated consts;

I plan to cover these gaps in follow-up PRs, as per @nikomatsakis's preference.

The basic strategy is to build up a *specialization graph* during
coherence checking. Insertion into the graph locates the right place
to put an impl in the specialization hierarchy; if there is no right
place (due to partial overlap but no containment), you get an overlap
error. Specialization is consulted when selecting an impl (of course),
and the graph is consulted when propagating defaults down the
specialization hierarchy.

You might expect that the specialization graph would be used during
selection -- i.e., when actually performing specialization. This is
not done for two reasons:

- It's merely an optimization: given a set of candidates that apply,
  we can determine the most specialized one by comparing them directly
  for specialization, rather than consulting the graph. Given that we
  also cache the results of selection, the benefit of this
  optimization is questionable.

- To build the specialization graph in the first place, we need to use
  selection (because we need to determine whether one impl specializes
  another). Dealing with this reentrancy would require some additional
  mode switch for selection. Given that there seems to be no strong
  reason to use the graph anyway, we stick with a simpler approach in
  selection, and use the graph only for propagating default
  implementations.

Trait impl selection can succeed even when multiple impls can apply,
as long as they are part of the same specialization family. In that
case, it returns a *single* impl on success -- this is the most
specialized impl *known* to apply. However, if there are any inference
variables in play, the returned impl may not be the actual impl we
will use at trans time. Thus, we take special care to avoid projecting
associated types unless either (1) the associated type does not use
`default` and thus cannot be overridden or (2) all input types are
known concretely.

r? @nikomatsakis

rustbuild: Fix cross compiling to FreeBSD

This commit fixes our support for cross compiling a compiler to run on FreeBSD.
Over the weekend I managed to get a cross compiler from Linux to FreeBSD [1]
which I hope to soon use to start producing FreeBSD nightly compilers. With the
`make dist` support added in #32237 we should be able to produce standard
rustc/rust-std packages for FreeBSD through a new slave with this cross compiler.

Currently, however, we don't "Just Work" when cross compiling FreeBSD and a
number of changes were required (part of this PR). They include:

* A few build fixes were needed in LLVM. Our own branch has been rebased on the
  actual 3.8 release and I applied one extra commit [2] which contains two fixes:

  1. The LLVM CMake build system passes the `-Wl,-z,defs` flag on many
     platforms, but *not* when `CMAKE_SYSTEM_NAME` is "FreeBSD". Unfortunately
     this doesn't take into account when we're cross compiling, and as predicted
     the build will fail if `-Wl,-z,defs` is passed (see [3] for more info). To
     fix this we test `TARGET_TRIPLE` instead of the `CMAKE_SYSTEM_NAME` which
     is what we're compiling for which fixes the problem.
  2. The `PATH_MAX` constant is apparently defined in a different location than
     many other Unix systems, so a file which required this just needed some
     help to keep compiling.

* Support for compiling compiler-rt with CMake has been added to rustbuild. It
  looks like it just emulates Linux in what it compiles as it didn't seem to
  naturally produce anything else... At least the architecture is right, so
  seems good for now at least!

[1]: https://github.com/alexcrichton/port-of-rust/blob/master/prebuilt/freebsd/Dockerfile
[2]: https://github.com/rust-lang/llvm/commit/be89e4b5
[3]: https://bugs.webkit.org/show_bug.cgi?id=138420

Add pretty printer output for `default`

Adjust error code

Parse fail test fixes

Fixes after rebase

Introduce ICE when the topmost projection restriction kicks in, as per issue #32205

Test fixes, added README for tests

Move tests to dedicated subdirectories

Fixes after a rebase

Address review comments

Move projection_mode to InferContext rather than SelectionContext to reduce chance of bugs

Forbid cross-polarity specializations

Add regression tests from initial implementation review

Add some debugging output for specialization graph assembly

Refactor core specialization and subst translation code to avoid
danger of inference variables floating around without their inference
context.

The main insight here is that, when we are translating substitutions
between two impls, *we already know that the more specific impl holds*,
so we do not need to add its obligations to the parameter
environment. Instead, we can just thread through the inference context
we used to show select the more specific impl in the first place.

Add more commentary for subst translation

Move specialization graph walks to iterators; make associated type
projection sensitive to "mode" (most importantly, trans vs middle).

This commit introduces several pieces of iteration infrastructure in the
specialization graph data structure, as well as various helpers for
finding the definition of a given item, given its kind and name.

In addition, associated type projection is now *mode-sensitive*, with
three possible modes:

- **Topmost**. This means that projection is only possible if there is a
    non-`default` definition of the associated type directly on the
    selected impl. This mode is a bit of a hack: it's used during early
    coherence checking before we have built the specialization
    graph (and therefore before we can walk up the specialization
    parents to find other definitions). Eventually, this should be
    replaced with a less "staged" construction of the specialization
    graph.

- **AnyFinal**. Projection succeeds for any non-`default` associated
    type definition, even if it is defined by a parent impl. Used
    throughout typechecking.

- **Any**. Projection always succeeds. Used by trans.

The lasting distinction here is between `AnyFinal` and `Any` -- we wish
to treat `default` associated types opaquely for typechecking purposes.

In addition to the above, the commit includes a few other minor review fixes.

Address basic nits from initial review

Assorted fixed after rebasing

Add some basic comments about how specialization fits into the rest of the trait machinery

Adjust tests for feature gate, and add tests for the gate itself

Add feature gate

Adjust coherence test to reflect that only the orphan rule prevents you from adding *generalizing* impls

Adjust test for new overlap message on default trait impls

Adjust overlap-related tests to account for cosmetic changes to error reporting behavior

Add tests for specialization on associated types

Implement default associated type inheritance.

This commit leverages the specialization graph infrastructure to allow
specializing trait implementations to leave off associated types for
which their parents have provided defaults.

It also modifies the type projection code to avoid projecting associated
types unless either (1) all input types are fully known or (2) the
available associated type is "final", i.e. not marked `default`.
This restriction is required for soundness, due to examples like:

```rust
trait Foo {
    type Assoc;
}

impl<T> Foo for T {
    default type Assoc = ();
}

impl Foo for u8 {
    type Assoc = String;
}

fn generic<T>() -> <T as Foo>::Assoc {
    () //~ ERROR
}

fn main() {
    let s: String = generic::<u8>();
    println!("{}", s); // bad news
}
```

Check for proper use of `default` keyword in specializing impls.

Add basic specialization tests, including for default item
inheritance. Updates some of the coherence tests as well.

Implement default method inheritance.

This commit leverages the specialization graph infrastructure to allow
specializing trait implementations to leave off methods for which their
parents have provided defaults.

It does not yet check that the `default` keyword is appropriately used
in such cases.

Add subst helper for inheriting FnSpace from another subst

Initial incorporation of specialization:

- Rewrites the overlap checker to instead build up a specialization
  graph, checking for overlap errors in the process.

- Use the specialization order during impl selection.

This commit does not yet handle associated types correctly, and assumes
that all items are `default` and are overridden.

Add specialization module.

The module contains a few important components:

- The `specialize` function, which determines whether one impl is a
  specialization of another.

- The `SpecializationGraph`, a per-trait graph recording the
  specialization tree. The main purpose of the graph is to allow
  traversals upwards (to less specialized impls) for discovering
  un-overridden defaults, and for ensuring that overridden items are
  allowed to be overridden.

Refactor `impl_trait_ref_and_oblig`, making it generally available as a utility

Hook `default` keyword into metadata and carry data through to typeck

Add `default` as contextual keyword, and parse it for impl items.

Remove useless vector accumulation in `type_vars_for_defs`

Fix existing comment typo.

linkchecker: Fix path checks on Windows

rustbuild: Refactor stage arguments away

The facet of a stage is rarely relevant when running a tool or building
something, it's all a question of what stage the *compiler* is built in. We've
already got a nice handy `Compiler` structure to carry this information, so
let's use it!

This refactors the signature of the `Build::cargo` function two ways:

1. The `stage` argument is removed, this was just duplicated with the `compiler`
   argument's stage field.
2. The `target` argument is now required. This was a bug where if the `--target`
   flag isn't passed then the snapshot stage0 compiler is always used, so we
   won't pick up any changes.

Much of the other changes in this commit are just propagating these decisions
outwards. For example many of the `Step` variants no longer have a stage
argument as they're baked into the compiler.

rustbuild: Use tool_cmd() instead of tool()

This sets up the dynamic loader path for dylibs required, so should fix the MSVC
build right now.

rustbuild: Fix 32-bit Windows build

Unfortunately on i686-pc-windows-gnu LLVM's answer to `--host-target` is
`x86_64-pc-windows-gnu` even though we're building in a 32-bit shell as well as
compiling 32-bit libraries. For now use Cargo's `HOST` environment variable to
determine whether we're doing a cross compilation or not.

Auto merge of #32169 - mitaa:anon-tip, r=nrc

Allow custom filenames for anonymous inputs

This came out of #29253 but doesn't fix it.

I thought it might be worth merging on its own nonetheless.

derive: improve hygiene for type parameters (see #2810)

When deriving Hash, RustcEncodable and RustcDecodable, the syntax extension
needs a type parameter to use in the inner method. They used to use __H, __S
and __D respectively. If this conflicts with a type parameter already declared
for the item, bad times result (see the test). There is no hygiene for type
parameters, but this commit introduces a better heuristic by concatenating the
names of all extant type parameters (and prepending __H).

derive: remove most __ strings FIXME(#2810)

This changes local variable names in all derives to remove leading
double-underscores. As far as I can tell, this doesn't break anything
because there is no user code in these generated functions except for
struct, field and type parameter names, and this doesn't cause shadowing
of those. But I am still a bit nervous.

fix FIXME(#6449) in #[derive(PartialOrd, Ord)]

This replaces some `if`s with `match`es. This was originally not possible
because using a global path in a match statement caused a "non-constant
path in constant expr" ICE. The issue is long since closed, though you still
hit it (as an error now, not an ICE) if you try to generate match patterns
using pat_lit(expr_path). But it works when constructing the patterns more
carefully.

derive: emit intrinsics::unreachable for impls on empty enums

fixes #31574

refactor derive-no-std test, add empty struct/enum

Allow custom filenames for anonymous inputs

Clean up cloning logic in compiletest.rs.

Auto merge of #30587 - oli-obk:eager_const_eval2, r=nikomatsakis

typestrong const integers

~~It would be great if someone could run crater on this PR, as this has a high danger of breaking valid code~~ Crater ran. Good to go.

----

So this PR does a few things:

1. ~~const eval array values when const evaluating an array expression~~
2. ~~const eval repeat value when const evaluating a repeat expression~~
3. ~~const eval all struct and tuple fields when evaluating a struct/tuple expression~~
4. remove the `ConstVal::Int` and `ConstVal::Uint` variants and replace them with a single enum (`ConstInt`) which has variants for all integral types
  * `usize`/`isize` are also enums with variants for 32 and 64 bit. At creation and various usage steps there are assertions in place checking if the target bitwidth matches with the chosen enum variant
5. enum discriminants (`ty::Disr`) are now `ConstInt`
6. trans has its own `Disr` type now (newtype around `u64`)

This obviously can't be done without breaking changes (the ones that are noticable in stable)
We could probably write lints that find those situations and error on it for a cycle or two. But then again, those situations are rare and really bugs imo anyway:

```rust
let v10 = 10 as i8;
let v4 = 4 as isize;
assert_eq!(v10 << v4 as usize, 160 as i8);
 ```

stops compiling because 160 is not a valid i8

```rust
struct S<T, S> {
    a: T,
    b: u8,
    c: S
}
let s = S { a: 0xff_ff_ff_ffu32, b: 1, c: 0xaa_aa_aa_aa as i32 };
```

stops compiling because `0xaa_aa_aa_aa` is not a valid i32

----

cc @eddyb @pnkfelix

related: https://github.com/rust-lang/rfcs/issues/1071

Auto merge of #32233 - Amanieu:volatile_store, r=eddyb

Fix LLVM assert with write_volatile

Fixes #29663

Auto merge of #32232 - jonas-schievink:issue31511, r=eddyb

Give a more accurate error on thin-to-fat ptr cast

Fixes #31511

rustbuild

Auto merge of #32231 - ruud-v-a:avx-cmp-blend, r=alexcrichton

Define AVX compare and blend intrinsics

This defines the following intrinsics:

 * `_mm256_blendv_pd`
 * `_mm256_blendv_ps`
 * `_mm256_cmp_pd`
 * `_mm256_cmp_ps`

I verified these locally.

Auto merge of #32226 - andoriyu:patch-2, r=alexcrichton

Fix. FreeBSD snapshot

Previous snapshot was complied with avx2 instructions by accident.

Actual file: http://people.freebsd.org/~davide/rust/rust-stage0-2016-02-17-4d3eebf-freebsd-x86_64-f38991fbb81c1cd8d0bbda396f98f13a55b42804.tar.bz2

/cc @alexcrichton @dcci

Auto merge of #32211 - achanda:ipv6-global, r=alexcrichton

Reject unspecified IP from global

Also fixed the test

Fix test fallout

Auto merge of #32227 - jseyfried:fix_import_resolution_bug, r=alexcrichton

Fix import resolution bug

This fixes #32222, which was introduced in #31726.

Fix LLVM assert with write_volatile

Auto merge of #32184 - ollie27:win_stdout, r=alexcrichton

Fixup stout/stderr on Windows

WriteConsoleW can fail if called with a large buffer so we need to slice
any stdout/stderr output.
However the current slicing has a few problems:
 1. It slices by byte but still expects valid UTF-8.
 2. The slicing happens even when not outputting to a console.
 3. panic! output is not sliced.

This fixes these issues by moving the slice to right before
WriteConsoleW and slicing on a char boundary.

Give a more accurate error on thin-to-fat ptr cast

Fixes #31511

Auto merge of #32229 - Manishearth:rollup, r=Manishearth

Rollup of 4 pull requests

- Successful merges: #32164, #32179, #32212, #32218
- Failed merges:

Regenerate x86 platform intrinsics

The exact command used was:

    $ cd src/etc/platform-intrinsics/x86
    $ python2 ../generator.py --format compiler-defs -i info.json   \
      sse.json sse2.json sse3.json ssse3.json sse41.json sse42.json \
      avx.json avx2.json fma.json                                   \
      > ../../../librustc_platform_intrinsics/x86.rs

Define AVX blend intrinsics

This defines the `_mm256_blendv_pd` and `_mm256_blendv_ps` intrinsics.
The `_mm256_blend_pd` and `_mm256_blend_ps` intrinsics are not available
as LLVM intrinsics. In Clang they are implemented using the
shufflevector builtin.

Intel reference: https://software.intel.com/en-us/node/524070.

Define AVX comparison intrinsics

This defines `_mm256_cmp_pd` and `_mm256_cmp_ps`.

Intel reference: https://software.intel.com/en-us/node/524075.

Rollup merge of #32218 - cantino:minor_book_typo_fixes, r=steveklabnik

Fix minor typos in doc.rust-lang.org/book

I've made a few typo and grammar fixes as I've been working through the book.

Rollup merge of #32212 - Manishearth:ice-cu, r=eddyb

Don't allow values for codegen-units less than 1

r? @eddyb

fixes #32191

Rollup merge of #32179 - srinivasreddy:remove_int_suffix, r=steveklabnik

Removed integer suffixes in libsyntax crate

Rollup merge of #32164 - nikomatsakis:fewer-errors, r=eddyb

Do not report errors from regionck if other errors were already reported

Do not report errors from regionck if other errors were already reported during the lifetime of this inferencer. Fixes #30580.

r? @arielb1

Auto merge of #31916 - nagisa:mir-passmgr-2, r=arielb1

Add Pass manager for MIR

A new PR, since rebasing the original one (https://github.com/rust-lang/rust/pull/31448) properly was a pain. Since then there has been several changes most notable of which:

1. Removed the pretty-printing with `#[rustc_mir(graphviz/pretty)]`, mostly because we now have `--unpretty=mir`, IMHO that’s the direction we should expand this functionality into;
2. Reverted the infercx change done for typeck, because typeck can make an infercx for itself by being a `MirMapPass`

r? @nikomatsakis

Add regression test for #32222

Fixes #32222

Refactor out methods `NameResolution::increment_outstanding_references` and
`NameResolution::decrement_outstanding_references`.

Auto merge of #32182 - bluss:string-from-is-str-owned, r=alexcrichton

Call str::to_owned in String::from and uninline it

Call str::to_owned in String::from and uninline it

These methods were already effectively equal, but now one calls
the other, and neither is marked inline.
String::from does not need to be inlined, it can be without it just like
str::to_owned and String::clone are.

Fixes #32163

Call str::to_owned in String::from and uninline it

String::from does not need to be inlined, it can be without it just like
str::to_owned and String::clone are.

Fix. FreeBSD snapshot

Previous snapshot was complied with avx2 instructions by accident.

Actual file: http://people.freebsd.org/~davide/rust/rust-stage0-2016-02-17-4d3eebf-freebsd-x86_64-f38991fbb81c1cd8d0bbda396f98f13a55b42804.tar.bz2

Auto merge of #32141 - jseyfried:fix_resolution_in_lexical_scopes, r=nikomatsakis

Fix name resolution in lexical scopes

Currently, `resolve_item_in_lexical_scope` does not check the "ribs" (type parameters and local variables). This can allow items that should be shadowed by type parameters to be named.

For example,
```rust
struct T { i: i32 }
fn f<T>() {
    let t = T { i: 0 }; // This use of `T` resolves to the struct, not the type parameter
}

mod Foo {
    pub fn f() {}
}
fn g<Foo>() {
    Foo::f(); // This use of `Foo` resolves to the module, not the type parameter
}
```

This PR changes `resolve_item_in_lexical_scope` so that it fails when the item is shadowed by a rib (fixes #32120).
This is a [breaking-change], but it looks unlikely to cause breakage in practice.

r? @nikomatsakis

Auto merge of #32217 - alexcrichton:fix-make-dist, r=brson

mk: Fix `make dist`

With the movement of the erro-index-generator and rustbook, need to update the
rules in `make dist`.

Auto merge of #32140 - ruud-v-a:avx-intrinsics, r=alexcrichton

Add AVX broadcast and conversion intrinsics

This adds the following intrinsics:

 * `_mm256_broadcast_pd`
 * `_mm256_broadcast_ps`
 * `_mm256_cvtepi32_pd`
 * `_mm256_cvtepi32_ps`
 * `_mm256_cvtpd_epi32`
 * `_mm256_cvtpd_ps`
 * `_mm256_cvtps_epi32`
 * `_mm256_cvtps_pd`
 * `_mm256_cvttpd_epi32`
 * `_mm256_cvttps_epi32`

The "avx" codegen feature must be enabled to use these.

Reject unspecified and loopback IP from global

Auto merge of #32112 - alexcrichton:fix-issues, r=aturon

std: Fix tracking issues and clean deprecated APIs

This PR fixes up a number of discrepancies found with tracking issues (some closed, some needed new ones, etc), and also cleans out all pre-1.8 deprecated APIs. The big beast here was dealing with `std::dynamic_lib`, and via many applications of a large hammer it's now out of the standard library.

Fix minor typos in doc.rust-lang.org/book

std: Clean out deprecated APIs

Removes all unstable and deprecated APIs prior to the 1.8 release. All APIs that
are deprecated in the 1.8 release are sticking around for the rest of this
cycle.

Some notable changes are:

* The `dynamic_lib` module was moved into `rustc_back` as the compiler still
  relies on a few bits and pieces.
* The `DebugTuple` formatter now special-cases an empty struct name with only
  one field to append a trailing comma.