macros: fix const expression invocations

Fixes #40136.
r? @nrc

Add missing tests for 'E-needstest' labeled issues

This PR adds missing tests for issue #35988, #19712, ~~#18627~~, #24947, #28600 and #34751.

Fix ICE: don't use `struct_variant` on enums

Fix #40221 and add unittest.

Fix #40221 and add unittest.

Inline function to avoid naming confusion.

Fixes the non-RFC requiring portion of #18394. The suggestion for a new token there probably needs to either be refiled onto rust-lang/rfcs if it's still relevant (may not be given Macros 2.0 work, not sure).

Add compile fail test for stmt_expr_attributes

Adds a missing feature gate test for `stmt_expr_attributes`. Issue #39059.

rustbuild: A few tweaks

Fixes https://github.com/rust-lang/rust/issues/40016
Fixes https://github.com/rust-lang/rust/issues/39507

r? @alexcrichton

Add comments

Add some comments

Move some code from x.py to bootstrap.py

Move the reference into a submodule

Part of https://github.com/rust-lang/rust/issues/39588

This moves the reference out into its own submodule. Right now, it's under my own account; I would assume that it should go under `rust-lang`, but I guess there's an argument for the nursery too? I can fix that up before we commit it.

r? @alexcrichton @brson

Let `-Crelocation-model` better control `-pie` linking

Prior to this, if relocation model in the target options was "pic", as
most targets have it, then the user's `-Crelocation-model` had no effect
on whether `-pie` would be used.  Only `-Clink-arg=-static` would have a
further override here.

Now we use `context::get_reloc_model`, which gives precedence to the
user's option, and if it's `RelocMode::PIC` we enable `-pie`.  This is
the same test as `context::is_pie_binary`, except that folds across all
`sess.crate_types`, not just the current one.

Fixes #35061.

Fix missing WhileLet pattern scope

Fix #40235

LLVM: Update submodule to include x86-interrupt ABI patches

Update LLVM submodule to `rust-llvm-2016-10-29` branch (commit https://github.com/rust-lang/llvm/commit/50ab09fb43f038e4f824eea6cb278f560d3e8621).

syntax: integrate `TokenStream`

Use `TokenStream` instead of `Vec<TokenTree>` in `TokenTree::Delimited` and elsewhere.
r? @nrc

More through normalization, Feb/Mar 2017 edition

Fix a few normalization bugs.

Fixes #27901.
Fixes #28828.
Fixes #38135.
Fixes #39363.
Fixes #39367.

rustbuild: Add support for compiling Cargo

This commit adds support to rustbuild for compiling Cargo as part of the release
process. Previously rustbuild would simply download a Cargo snapshot and
repackage it. With this change we should be able to turn off artifacts from the
rust-lang/cargo repository and purely rely on the artifacts Cargo produces here.

The infrastructure added here is intended to be extensible to other components,
such as the RLS. It won't exactly be a one-line addition, but the addition of
Cargo didn't require too much hooplah anyway.

The process for release Cargo will now look like:

* The rust-lang/rust repository has a Cargo submodule which is used to build a
  Cargo to pair with the rust-lang/rust release
* Periodically we'll update the cargo submodule as necessary on rust-lang/rust's
  master branch
* When branching beta we'll create a new branch of Cargo (as we do today), and
  the first commit to the beta branch will be to update the Cargo submodule to
  this exact revision.
* When branching stable, we'll ensure that the Cargo submodule is updated and
  then make a stable release.

Backports to Cargo will look like:

* Send a PR to cargo's master branch
* Send a PR to cargo's release branch (e.g. rust-1.16.0)
* Send a PR to rust-lang/rust's beta branch updating the submodule
* Eventually send a PR to rust-lang/rust's master branch updating the submodule

For reference, the process to add a new component to the rust-lang/rust release
would look like:

* Add `$foo` as a submodule in `src/tools`
* Add a `tool-$foo` step which compiles `$foo` with the specified compiler,
  likely mirroring what Cargo does.
* Add a `dist-$foo` step which uses `src/tools/$foo` and the `tool-$foo` output
  to create a rust-installer package for `$foo` likely mirroring what Cargo
  does.
* Update the `dist-extended` step with a new dependency on `dist-$foo`
* Update `src/tools/build-manifest` for the new component.

Prior to this, if relocation model in the target options was "pic", as
most targets have it, then the user's `-Crelocation-model` had no effect
on whether `-pie` would be used.  Only `-Clink-arg=-static` would have a
further override here.

Now we use `context::get_reloc_model`, which gives precedence to the
user's option, and if it's `RelocMode::PIC` we enable `-pie`.  This is
the same test as `context::is_pie_binary`, except that folds across all
`sess.crate_types`, not just the current one.

Add compile fail test for SIMD

This completes the missing SIMD test task for issue #39059.

This commit adds support to rustbuild for compiling Cargo as part of the release
process. Previously rustbuild would simply download a Cargo snapshot and
repackage it. With this change we should be able to turn off artifacts from the
rust-lang/cargo repository and purely rely on the artifacts Cargo produces here.

The infrastructure added here is intended to be extensible to other components,
such as the RLS. It won't exactly be a one-line addition, but the addition of
Cargo didn't require too much hooplah anyway.

The process for release Cargo will now look like:

* The rust-lang/rust repository has a Cargo submodule which is used to build a
  Cargo to pair with the rust-lang/rust release
* Periodically we'll update the cargo submodule as necessary on rust-lang/rust's
  master branch
* When branching beta we'll create a new branch of Cargo (as we do today), and
  the first commit to the beta branch will be to update the Cargo submodule to
  this exact revision.
* When branching stable, we'll ensure that the Cargo submodule is updated and
  then make a stable release.

Backports to Cargo will look like:

* Send a PR to cargo's master branch
* Send a PR to cargo's release branch (e.g. rust-1.16.0)
* Send a PR to rust-lang/rust's beta branch updating the submodule
* Eventually send a PR to rust-lang/rust's master branch updating the submodule

For reference, the process to add a new component to the rust-lang/rust release
would look like:

* Add `$foo` as a submodule in `src/tools`
* Add a `tool-$foo` step which compiles `$foo` with the specified compiler,
  likely mirroring what Cargo does.
* Add a `dist-$foo` step which uses `src/tools/$foo` and the `tool-$foo` output
  to create a rust-installer package for `$foo` likely mirroring what Cargo
  does.
* Update the `dist-extended` step with a new dependency on `dist-$foo`
* Update `src/tools/build-manifest` for the new component.

[MIR] improve operand lifetimes

r? @EddyB

In MIR construction, operands need to live exactly until they are used,
which is during the (sub)expression that made the call to `as_operand`.

Before this PR, operands lived until the end of the temporary scope,
which was sometimes unnecessarily longer and sometimes too short.

Fixes #38669.

Reduce std_unicode’s public API

 * Only keep one copy of the `UTF8_CHAR_WIDTH` table instead of one of each of libcore and libstd_unicode.
* Move the `utf8_char_width` function to `core::str` under the `str_internals` unstable feature.
* Remove `std_unicode::str::is_utf16`. It was only accessible through the `#[unstable]` crate std_unicode. It has never been used in the compiler or standard library since 47e7a05a added it in 2012 “for OS API interop”. It can be replaced with a one-liner:

   ```rust
   fn is_utf16(slice: &[u16]) -> bool {
       std::char::decode_utf16(s).all(|r| r.is_ok())
   }
   ```

convert AdtDef::destructor to on-demand

This removes the `Cell` from `AdtDef`. Also, moving destructor validity
checking to on-demand (forced during item-type checking) ensures that
invalid destructors can't cause ICEs.

Fixes #38868.
Fixes #40132.

r? @EddyB

rustbuild: use deterministic step ordering and respect path order on the command-line.

Restores similar behavior to `make` rules, where:
* the step order was always the same, e.g. the testsuite order in `make check`
* `make check-stage1-{cfail,rpass}` would *always* run `cfail` before `rpass`
  * `./x.py test--stage 1 src/test/{compile-fail,run-pass}` is now equivalent

r? @alexcrichton