As discussed in PR #78267, for example:

* #78267 (comment)
* #78267 (comment)

Co-authored-by: Joshua Nelson <[email protected]>

Including llvm-as adds the ability to include assembly language fragments
that can be inlined using LTO.

Per Mark's recommendation at:
#78963 (comment)

This bumps the minimal tested llvm version to 9.
This should enable supporting newer LLVM features (and CPU extensions).

apparently llvm-8-tools already had llvm-8-dev as a dependency
which was removed in llvm-9-tools, so we need to explicitly pull
llvm-9-dev to make a build

This commit grepped for LLVM_VERSION_GE, LLVM_VERSION_LT, get_major_version and
min-llvm-version and statically evaluated every expression possible
(and sensible) assuming that the LLVM version is >=9 now

…ersion

The function was only used in LLVM 8 compatibility code
and was found and flagged by dead code detection and now removed.

as requested in the review and argued that this is only consistent with later LLVM upgrades

If the LLVM was externally provided, then we don't currently copy artifacts into
the sysroot. This is not necessarily the right choice (in particular, it will
require the LLVM dylib to be in the linker's load path at runtime), but the
common use case for external LLVMs is distribution provided LLVMs, and in that
case they're usually in the standard search path (e.g., /usr/lib) and copying
them here is going to cause problems as we may end up with the wrong files and
isn't what distributions want.

This behavior may be revisited in the future though.

This looks like it was forgotten to get updated in #74482 and wasm with
threads isn't built on CI so we didn't catch this by accident.

The inliner looks if a sanitizer is enabled before considering
`no_sanitize` attribute as possible source of incompatibility.

The MIR inlining could happen in a crate with sanitizer disabled, but
code generation in a crate with sanitizer enabled, thus the attribute
would be incorrectly ignored.

To avoid the issue never inline functions with different `no_sanitize`
attributes.

The information about cold attribute is lost during inlining,
Avoid the issue by never inlining cold functions.

The callee body is already transformed; the condition is always false.

During inlining, the callee body is normalized and has types revealed,
but some of locals corresponding to the arguments might come from the
caller body which is not. As a result the caller body does not pass
validation without additional normalization.

This allows using bootstrap with https://github.com/Canop/bacon.

Restructured the code a little, to allow getting both the mir::Body and
coverage graph.

commit c547d5fabcd756515afa7263ee5304965bb4c497
Author: C <[email protected]>
Date:   Sat Oct 31 11:22:23 2020 +0000

    test: updating ui/hygiene/panic-location.rs expected

commit 2af03769c4ffdbbbad75197a1ad0df8c599186be
Author: C <[email protected]>
Date:   Sat Oct 31 10:43:30 2020 +0000

    fix: documentation unresolved link

commit c4b0df361ce27d7392d8016229f2e0265af32086
Author: C <[email protected]>
Date:   Sat Oct 31 02:58:31 2020 +0000

    style: compiling with Rust's style guidelines

commit bdd2de5f3c09b49a18e3293f2457fcab25557c96
Author: C <[email protected]>
Date:   Sat Oct 31 02:56:31 2020 +0000

    refactor: removing ignore-tidy-filelength

commit fcc4b3bc41f57244c65ebb8e4efe4cbc9460b5a9
Author: C <[email protected]>
Date:   Sat Oct 31 02:51:35 2020 +0000

    refactor: moving trait RingSlices to ring_slices.rs

commit 2f0cc539c06d8841baf7f675168f68ca7c21e68e
Author: C <[email protected]>
Date:   Sat Oct 31 02:46:09 2020 +0000

    refactor: moving struct PairSlices to pair_slices.rs

commit a55d3ef1dab4c3d85962b3a601ff8d1f7497faf2
Author: C <[email protected]>
Date:   Sat Oct 31 02:31:45 2020 +0000

    refactor: moving struct Iter to iter.rs

commit 76ab33a12442a03726f36f606b4e0fe70f8f246b
Author: C <[email protected]>
Date:   Sat Oct 31 02:24:32 2020 +0000

    refactor: moving struct IntoIter into into_iter.rs

commit abe0d9eea2933881858c3b1bc09df67cedc5ada5
Author: C <[email protected]>
Date:   Sat Oct 31 02:19:07 2020 +0000

    refactor: moving struct IterMut into iter_mut.rs

commit 70ebd6420335e1895e2afa2763a0148897963e24
Author: C <[email protected]>
Date:   Sat Oct 31 01:49:15 2020 +0000

    refactor: moved macros into macros.rs

commit b08dd2add994b04ae851aa065800bd8bd6326134
Author: C <[email protected]>
Date:   Sat Oct 31 01:05:36 2020 +0000

    refactor: moving vec_deque.rs to vec_deque/mod.rs

Co-authored-by: matthewjasper <[email protected]>

Co-authored-by: varkor <[email protected]>

Do not call `unwrap` with `signatures` option enabled

Fixes #75229
Didn't add a test since I couldn't set `RUST_SAVE_ANALYSIS_CONFIG` even with `rustc-env`.

refactor: removing alloc::collections::vec_deque ignore-tidy-filelength

This PR removes the need for ignore-tidy-filelength for alloc::collections::vec_deque which is part of the issue #60302

It is probably easiest to review this PR by looking at it commit by commit rather than looking at the overall diff.

Bump minimal supported LLVM version to 9

This bumps the minimal tested llvm version to 9.
This should enable supporting newer LLVM features (and CPU extensions).

This was motived by #78361 having to drop features because of LLVM 8 not supporting certain CPU extensions yet.
This was declared relatively uncontroversial on [Zulip](https://rust-lang.zulipchat.com/#narrow/stream/182449-t-compiler.2Fhelp/topic/Min.20Supported.20LLVM.20Upgrade.20Process.3F/near/215957859).

Paging ```@eddyb``` because there was a comment in the [dockerfile](https://github.com/rust-lang/rust/blob/master/src/ci/docker/host-x86_64/x86_64-gnu-llvm-8/Dockerfile#L42) describing a hack (which I don't quite understand) which was also blocked by not having LLVM 9.

Explicitly checking for or-pattern before test

Fixes #72680

cc #54883

r? ```@varkor```

test: add `()=()=()=...` to weird-exprs.rs

Idea from #71156 (comment) 😄

Builds on nightly since #78748 has been merged.

Add a test for r# identifiers

I'm not entirely sure I properly ran the test locally (I think so though), waiting for CI to confirm. :)

``````@rustbot`````` modify labels: T-rustdoc

r? ``````@jyn514``````

…andry

Added some unit tests as requested

As discussed in PR #78267, for example:

* #78267 (comment)
* #78267 (comment)

r? ``````@tmandry``````
FYI: ``````@wesleywiser``````

This is pretty much self contained, but depending on feedback and timing, I may have a chance to add a few more unit tests requested against `counters.rs`. I'm looking at those now.

Never inline C variadics, cold functions, functions with incompatible attributes ...

... and fix generator inlining.

Closes #67863.
Closes #78859.

Include llvm-as in llvm-tools-preview component

Including `llvm-as` adds the ability to include assembly language fragments that can be inlined using LTO while making sure the correct version of LLVM is always used.

Normalize function type during validation

During inlining, the callee body is normalized and has types revealed,
but some of locals corresponding to the arguments might come from the
caller body which is not. As a result the caller body does not pass
validation without additional normalization.

Closes #78442.

Fix rustc_ast_pretty print_qpath resulting in invalid macro input

related #76874 (third case)

### Issue:

The input for a procedural macro is incorrect, for the rust code:
```rust

mod m {
    pub trait Tr {
        type Ts: super::Tu;
    }
}

trait Tu {
    fn dummy() { }
}

#[may_proc_macro]
fn foo() {
    <T as m::Tr>::Ts::dummy();
}
```
the macro will get the input:
```rust
fn foo() {
    <T as m::Tr>::dummy();
}
```
Thus `Ts` has disappeared.

### Fix:

This is due to invalid pretty print of qpath. This PR fix it.

Avoid installing external LLVM dylibs

If the LLVM was externally provided, then we don't currently copy artifacts into
the sysroot. This is not necessarily the right choice (in particular, it will
require the LLVM dylib to be in the linker's load path at runtime), but the
common use case for external LLVMs is distribution provided LLVMs, and in that
case they're usually in the standard search path (e.g., /usr/lib) and copying
them here is going to cause problems as we may end up with the wrong files and
isn't what distributions want.

This behavior may be revisited in the future though.

Fixes #78932.

Fix an intrinsic invocation on threaded wasm

This looks like it was forgotten to get updated in #74482 and wasm with
threads isn't built on CI so we didn't catch this by accident.

rustc_target: Fix dash vs underscore mismatches in option names

Fixes #78981 (regression from #78875, the old option names used dashes)

rustc_expand: Mark inner `#![test]` attributes as soft-unstable

Custom inner attributes are feature gated (#54726) except for attributes having name `test` literally, which are not gated for historical reasons.

`#![test]` is an inner proc macro attribute, so it has all the issues described in #54726 too.
This PR gates it with the `soft_unstable` lint.

Add `--color` support to bootstrap

When running under external utilities which wrap x.py, it can be convenient to force color support on.

cleanup: Remove `ParseSess::injected_crate_name`

Its only remaining use is in pretty-printing where the necessary information can be easily re-computed.

Make `_` an expression, to discard values in destructuring assignments

This is the third and final step towards implementing destructuring assignment (RFC: rust-lang/rfcs#2909, tracking issue: #71126). This PR is the third and final part of #71156, which was split up to allow for easier review.

With this PR, an underscore `_` is parsed as an expression but is allowed *only* on the left-hand side of a destructuring assignment. There it simply discards a value, similarly to the wildcard `_` in patterns. For instance,
```rust
(a, _) = (1, 2)
```
will simply assign 1 to `a` and discard the 2. Note that for consistency,
```
_ = foo
```
is also allowed and equivalent to just `foo`.

Thanks to ```@varkor``` who helped with the implementation, particularly around pre-expansion gating.

r? ```@petrochenkov```

astconv: extract closures into a separate trait

Am currently looking into completely removing `check_generic_arg_count` and `create_substs_for_generic_args` was somewhat difficult to understand for me so I moved these closures into a trait.

This should not have changed the behavior of any of these methods

Implement BTreeMap::retain and BTreeSet::retain

Adds new methods `BTreeMap::retain` and `BTreeSet::retain`.  These are implemented on top of `drain_filter` (#70530).

The API of these methods is identical to `HashMap::retain` and `HashSet::retain`, which were implemented in #39560 and stabilized in #36648.  The docs and tests are also copied from HashMap/HashSet.

The new methods are unstable, behind the `btree_retain` feature gate, with tracking issue #79025.  See also rust-lang/rfcs#1338.

…ievink

Validate that locals have a corresponding `LocalDecl`

Fixes #73356.

rustc_resolve: Make `macro_rules` scope chain compression lazy

As suggested in #78826 (comment).

Move Steal to rustc_data_structures.

Rename clean::{ItemEnum -> ItemKind}, clean::Item::{inner -> kind}

r? ```@petrochenkov```
cc ```@GuillaumeGomez```

Follow-up to #77820 (comment).