Make compiletest do exact matching on triples

This avoids the issues of the previous substring matching, ensuring `ARCH_TABLE` and `OS_TABLE` will no longer contain redundant entries. Fixes rust-lang#48893.

r? @rkruppe

…uietMisdreavus

Put `#[macro_use] extern crate <crate>` before fn main() in doctests

Closes rust-lang#49174.

…-links, r=QuietMisdreavus

Fix automatic urls with backticks

Fixes rust-lang#49164.

r? @QuietMisdreavus

Run the `run-make` tests last, so more tests run on Windows when `make` is unavailable

Just rust-lang#47996 again.

r? @Mark-Simulacrum

…rom-Env, r=nikomatsakis

Implement Chalk lowering rule "Implemented-From-Env"

This extends the Chalk lowering pass with the "Implemented-From-Env" rule for generating program clauses from a trait definition as part of rust-lang#49177.

r? @nikomatsakis

Don't check interpret_interner when accessing a static to fix miri mutable statics

Mutable statics don't work in my PR to fix the standalone [miri](https://github.com/solson/miri), as init_static didn't get called when the interpret_interner already contained a entry for the static, which is always immutable.

cc rust-lang/miri#364

…l-the-time, r=alexcrichton

whitelist every target feature for rustdoc

When rust-lang/stdarch#367 was attempted to be upstreamed, it failed to document on non-x86 targets because it made every intrinsic visible, even the ones on foreign arches. This change makes it so that whenever rustdoc asks for the target feature whitelist, it gets a list of every feature known to every arch in `rustc_trans/llvm_util.rs`.

Before pushing, i temporarily updated the `stdsimd` submodule to include the `doc(cfg)` change, generated documentation for `aarch64-unknown-linux-gnu`, and it completed without a problem. The generated `core::arch` docs contained complete submodules for all main arches.

fix vector fmin/fmax non-fast/fast intrinsics NaN handling

This bugs shows up in release mode tests of `stdsimd`: rust-lang/stdarch#391 . The intrinsics are thoroughly tested there for roundoff errors, NaN, and overflow behavior.

The problem was that the non-fast intrinsics where specifying `NoNaNs == true`, which meant that they don't support NaNs. This is incorrect, the non-fast intrinsics should handle NaNs properly.

Also, the "fast" intrinsics where specifying `NoNaNs == false` which meant that they support NaNs and then fast-math, which probably disables this support. This was not intended either.

I've added a comment specifying what the boolean flags do.

…richton

dpl 1.9.5 has been released, revert rust-lang#49217.

dpl 1.9.5 has been released which includes travis-ci/dpl#789, so we could move back to the standard Travis settings before that `s3-eager-autoload` branch is removed.

Pass attributes to hir::TyParam

Required by servo/servo#20264
Discussed here: https://gitter.im/servo/servo?at=5aafdcd1012ff2bf681da97a

CC @nikomatsakis

…odCall, r=estebank

Fix type_dependent_defs ICE on method calls

Fixes rust-lang#49241.

This reverts commit 9f792e1.

… r=alexcrichton

Add an example of lossy decoding to str::Utf8Error docs

CC rust-lang#33906

…ver, r=SimonSapin

replace `convert::Infallible` with `!`

…lambda-building

This prevents explicit `-> _` return type annotations for closures generated by `lambda`.

…awn()

Rollup of 23 pull requests

- Successful merges: rust-lang#48374, rust-lang#48596, rust-lang#48759, rust-lang#48939, rust-lang#49029, rust-lang#49069, rust-lang#49093, rust-lang#49109, rust-lang#49117, rust-lang#49140, rust-lang#49158, rust-lang#49188, rust-lang#49189, rust-lang#49209, rust-lang#49211, rust-lang#49216, rust-lang#49225, rust-lang#49231, rust-lang#49234, rust-lang#49242, rust-lang#49244, rust-lang#49105, rust-lang#49038
- Failed merges:

Fix the conversion between bit representations and i128 representations

fixes rust-lang#49181

the `Discr` type now encodes the bit representation instead of `i128` or `u128` casted to `u128`.

r? @eddyb

This commit is an implementation of adding custom sections to wasm artifacts in
rustc. The intention here is to expose the ability of the wasm binary format to
contain custom sections with arbitrary user-defined data. Currently neither our
version of LLVM nor LLD supports this so the implementation is currently custom
to rustc itself.

The implementation here is to attach a `#[wasm_custom_section = "foo"]`
attribute to any `const` which has a type like `[u8; N]`. Other types of
constants aren't supported yet but may be added one day! This should hopefully
be enough to get off the ground with *some* custom section support.

The current semantics are that any constant tagged with `#[wasm_custom_section]`
section will be *appended* to the corresponding section in the final output wasm
artifact (and this affects dependencies linked in as well, not just the final
crate). This means that whatever is interpreting the contents must be able to
interpret binary-concatenated sections (or each constant needs to be in its own
custom section).

To test this change the existing `run-make` test suite was moved to a
`run-make-fulldeps` folder and a new `run-make` test suite was added which
applies to all targets by default. This test suite currently only has one test
which only runs for the wasm target (using a node.js script to use `WebAssembly`
in JS to parse the wasm output).

This commit adds a new attribute to the Rust compiler specific to the wasm
target (and no other targets). The `#[wasm_import_module]` attribute is used to
specify the module that a name is imported from, and is used like so:

    #[wasm_import_module = "./foo.js"]
    extern {
        fn some_js_function();
    }

Here the import of the symbol `some_js_function` is tagged with the `./foo.js`
module in the wasm output file. Wasm-the-format includes two fields on all
imports, a module and a field. The field is the symbol name (`some_js_function`
above) and the module has historically unconditionally been `"env"`. I'm not
sure if this `"env"` convention has asm.js or LLVM roots, but regardless we'd
like the ability to configure it!

The proposed ES module integration with wasm (aka a wasm module is "just another
ES module") requires that the import module of wasm imports is interpreted as an
ES module import, meaning that you'll need to encode paths, NPM packages, etc.
As a result, we'll need this to be something other than `"env"`!

Unfortunately neither our version of LLVM nor LLD supports custom import modules
(aka anything not `"env"`). My hope is that by the time LLVM 7 is released both
will have support, but in the meantime this commit adds some primitive
encoding/decoding of wasm files to the compiler. This way rustc postprocesses
the wasm module that LLVM emits to ensure it's got all the imports we'd like to
have in it.

Eventually I'd ideally like to unconditionally require this attribute to be
placed on all `extern { ... }` blocks. For now though it seemed prudent to add
it as an unstable attribute, so for now it's not required (as that'd force usage
of a feature gate). Hopefully it doesn't take too long to "stabilize" this!

cc rust-lang-nursery/rust-wasm#29

It'd be pretty buggy if `None` were supplied anyway; we'd skip over
in-band lifetimes completely!

`'_` is illegal in structs; this currently gets a duplicate error

Deprecated forms of elision are not supported.

This commit modifies the UserAssertTy statement to take a canonicalized
type rather than a regular type so that we can handle the case where the
user provided type contains a inference variable.

Fixes broken RLS tests/build

This way, we don't have to repeat it.

The use of tcx/gcx in this function is subtle.

This helps to make clear where *global* lifetimes are needed
in `coerce_unsized_info`

This assertion was preventing `./x.py install rustfmt` if attempted
without an "extended" build configuration, but it actually builds and
installs just fine.

This commit moves away from caching on Travis to our own caching on S3 for
caching docker layers between builds. Unfortunately the Travis caches have over
time had a few critical pain points:

* Caches are only updated for successful builds, meaning that if a build times
  out or fails in a different location the sucessfully-created docker images
  isn't always cached. While this makes sense as a general rule of caches it
  hurts our use cases.

* Caches are per-branch and builder which means that we don't have a separate
  cache on each release channel. All our merges go through the `auto` branch
  which means that they're all sharing the same cache, even those for merging to
  master/beta. This means that PRs which switch between master/beta will keep
  rebuilting and having cache misses.

* Caches have historically been invaliated somewhat regularly a little more
  aggressively than we'd want (I think).

* We don't always need to update the contents of the cache if the Docker image
  didn't change at all, and saving off the docker layers can sometimes be quite
  expensive.

For all these reasons this commit drops the usage of Travis's built-in caching
support. Instead our own caching is used by storing blobs to S3. Normally this
would be a very risky endeavour but we're basically priming a cache for a cache
(docker) so if we get this wrong the failure mode is longer builds, not stale
caches. We'll notice that pretty quickly and hopefully fix it!

The logic here is inserted directly into the `src/ci/docker/run.sh` script to
download an image based on a shasum of the `Dockerfile` and other assorted files.
This blob, if found, is loaded into docker and we record what layers were
inserted. After docker finishes the build (hopefully quickly with lots of cache
hits) we then see the sha of the final image. If it's one of the layers we
loaded then there's no need to update the cache. Otherwise we upload our layers
to the global cache, possibly overwriting what we previously just downloaded.

This is hopefully a step towards mitigating rust-lang#49278 although it doesn't
completely fix it as it means we'll still probably have to retry builds that
bust the cache.

Update RLS and Rustfmt

Fixes broken RLS tests/build

r? @alexcrichton

Adds intrinsics::exact_div to take advantage of the unsafe, which reduces the implementation from
```asm
    sub rcx, rdx
    mov rax, rcx
    sar rax, 63
    shr rax, 62
    lea rax, [rax + rcx]
    sar rax, 2
    ret
```
down to
```asm
    sub rcx, rdx
    sar rcx, 2
    mov rax, rcx
    ret
```
(for `*const i32`)

In addition to the `Fn*` family of traits, closures now implement `Copy` (and similarly `Clone`) if all of the captures do.

Add 12 num::NonZero* types for primitive integers, deprecate core::nonzero

RFC: rust-lang/rfcs#2307
Tracking issue: ~~rust-lang#27730 rust-lang#49137
Fixes rust-lang#27730

…xcrichton

Command: Support posix_spawn() on FreeBSD/OSX/GNU Linux

…r=nikomatsakis

rustc: Add a `#[wasm_custom_section]` attribute

This commit is an implementation of adding custom sections to wasm artifacts in
rustc. The intention here is to expose the ability of the wasm binary format to
contain custom sections with arbitrary user-defined data. Currently neither our
version of LLVM nor LLD supports this so the implementation is currently custom
to rustc itself.

The implementation here is to attach a `#[wasm_custom_section = "foo"]`
attribute to any `const` which has a type like `[u8; N]`. Other types of
constants aren't supported yet but may be added one day! This should hopefully
be enough to get off the ground with *some* custom section support.

The current semantics are that any constant tagged with `#[wasm_custom_section]`
section will be *appended* to the corresponding section in the final output wasm
artifact (and this affects dependencies linked in as well, not just the final
crate). This means that whatever is interpreting the contents must be able to
interpret binary-concatenated sections (or each constant needs to be in its own
custom section).

To test this change the existing `run-make` test suite was moved to a
`run-make-fulldeps` folder and a new `run-make` test suite was added which
applies to all targets by default. This test suite currently only has one test
which only runs for the wasm target (using a node.js script to use `WebAssembly`
in JS to parse the wasm output).

…chenkov

Improve lint for type alias bounds

First of all, I learned just today that I was wrong assuming that the bounds in type aliases are entirely ignored: It turns out they are used to resolve associated types in type aliases. So:
```rust
type T1<U: Bound> = U::Assoc; // compiles
type T2<U> = U::Assoc; // fails
type T3<U> = <U as Bound>::Assoc; // "correct" way to write this, maybe?
```
I am sorry for creating this mess.

This PR changes the wording of the lint accordingly. Moreover, since just removing the bound is no longer always a possible fix, I tried to detect cases like `T1` above and show a helpful message to the user:
```
warning: bounds on generic parameters are not enforced in type aliases
  --> $DIR/type-alias-bounds.rs:57:12
   |
LL | type T1<U: Bound> = U::Assoc; //~ WARN not enforced in type aliases
   |            ^^^^^
   |
   = help: the bound will not be checked when the type alias is used, and should be removed
help: use absolute paths (i.e., <T as Trait>::Assoc) to refer to associated types in type aliases
  --> $DIR/type-alias-bounds.rs:57:21
   |
LL | type T1<U: Bound> = U::Assoc; //~ WARN not enforced in type aliases
   |                     ^^^^^^^^
```
I am not sure if I got this entirely right. Ideally, we could provide a suggestion involving the correct trait and type name -- however, while I have access to the HIR in the lint, I do not know how to get access to the resolved name information, like which trait `Assoc` belongs to above. The lint does not even run if that resolution fails, so I assume that information is available *somewhere*...

This is a follow-up for (parts of) rust-lang#48326. Also see rust-lang#21903.

This changes the name of a lint, but that lint was just merged to master yesterday and has never even been on beta.

…corners-of-rustdoc, r=frewsxcv

add an "unstable features" chapter to the rustdoc book

There are several rustdoc features that currently are undocumented, but also don't fit with the rest of the Rustdoc Book since they're also unstable. Some of these have corresponding feature gates and chapters in the Unstable Book, but many don't, and i wanted a place to talk about them officially.

Goal: talk about everything rustdoc can do that needs nightly

- [x] Feature gates (extensions to the doc attribute that can be caught by the compiler)
  - [x] doc(cfg)
  - [x] doc(masked)
  - [x] doc(spotlight)
  - [x] doc(include)
- [x] Command-line flags (features that require a CLI flag to use, where the flag itself is a `-Z` command or otherwise requires `-Z unstable-options` before rustdoc will accept it)
  - [x] markdown-before-content/markdown-after-content
  - [x] playground-url
  - [x] display-warnings
  - [x] crate-version
  - [x] linker
  - [x] sort-modules-by-appearance
  - [x] themes/theme-checker
  - [x] resource-suffix
  - [x] `-Z force-unstable-if-unmarked`
- [x] Nightly-gated functionality (features that are gated by requiring a nightly build without needing a CLI flag or a feature gate to unlock)
  - [x] intra-links
  - [x] error numbers for `compile_fail` doctests

Misc changes from my parallel rustc branch

r? @michaelwoerister

Remove core::fmt::num::Decimal

Before ebf9e1a, it was used for Display::fmt, but ebf9e1a replaced
that with a faster implementation, and nothing else uses it.

…, r=oli-obk

Reduce the diagnostic spam when multiple fields are missing in pattern

Fix rust-lang#47457.

Document only-X test header

This was added in rust-lang#47487 without documentation.

…ebank

Produce nice array lengths on a best effort basis

fixes rust-lang#49208

r? @estebank

…chton

Use GNU version of fgrep/egrep tool if available

It is mostly for BSD system. Some tests (run-make/issue-35164 and
run-make/cat-and-grep-sanity-check) are failing with BSD
fgrep, whereas they pass with gnu version (gfgrep).

Add test for issue-48238

Fixes rust-lang#48238
test case made from comments in rust-lang#48238

…rollup

Rollup of 15 pull requests

- Successful merges: rust-lang#48265, rust-lang#48528, rust-lang#48552, rust-lang#48624, rust-lang#48883, rust-lang#48909, rust-lang#49028, rust-lang#49030, rust-lang#49102, rust-lang#49160, rust-lang#49169, rust-lang#49203, rust-lang#49262, rust-lang#49272, rust-lang#49295
- Failed merges: rust-lang#48942, rust-lang#49035

Fixes rust-lang#49215

This was attempted but left incomplete in PR rust-lang#42664, where only the toml
file was removed.

If there is potential ambiguity after stabilizing those candidates, a
warning will be emitted.

…eId`.

This clarifies the intent of whether to emit deprecated lint or not.

…ons.

…-return, r=Mark-Simulacrum

Use the same RUSTFLAGS for building and testing `bootstrap`

This avoids recompiling the whole dependency graph twice for every `./x.py test` run.

Fixes rust-lang#49215