Add a test that rustc compiles and links separately

Exclude unnecessary info from CodegenResults

`foreign_module` and `wasm_import_module` are not needed for linking,
and hence can be removed from CodegenResults.

Auto merge of #80242 - Nadrieril:explain-and-factor-splitting, r=varkor

Clarify constructor splitting in exhaustiveness checking

I reworked the explanation of the algorithm completely to make it properly account for the various extensions we've added. This includes constructor splitting, which was previously not clearly included in the algorithm. This makes wildcards less magical; I added some detailed examples; and this distinguishes clearly between constructors that only make sense in patterns (like ranges) and those that make sense for values (like `Some`). This reformulation had been floating around in my mind for a while, and I'm quite happy with how it turned out. Let me know how you feel about it.
I also factored out all three cases of splitting (wildcards, ranges and slices) into dedicated structs to encapsulate the complicated bits.
I measured no perf impact but I don't trust my local measurements for refactors since https://github.com/rust-lang/rust/pull/79284.

r? `@varkor`
`@rustbot` modify labels: +A-exhaustiveness-checking

Auto merge of #80177 - tgnottingham:foreign_defpathhash_registration, r=Aaron1011

rustc_query_system: explicitly register reused dep nodes

Register nodes that we've reused from the previous session explicitly
with `OnDiskCache`. Previously, we relied on this happening as a side
effect of accessing the nodes in the `PreviousDepGraph`. For the sake of
performance and avoiding unintended side effects, register explictily.

Auto merge of #80071 - jyn514:timings, r=Mark-Simulacrum

Add more timing info to rustdoc

This helped me confirm in https://github.com/rust-lang/rust/issues/79103#issuecomment-745737864 that get_blanket_impls is indeed what's taking all the time on stm32.

r? `@Mark-Simulacrum`

Fix a comment

Apply suggestions from code review

Co-authored-by: varkor <github@varkor.com>

Simplify field filtering

Make the special "missing patterns" constructor real

Completely rework the explanation of the algorithm

Pass `Matrix` explicitly instead of via `PatCtxt`

Inline the constructor-specific `split` functions

Inline `all_constructors`

Rebrand `MissingConstructors` as `SplitWildcard`

Factor out `SplitVarLenSlice` used for slice splitting

Run the annoying lint separately

Factor out `SplitIntRange` used for integer range splitting

Add some tests

Auto merge of #79451 - usbalbin:array_zip, r=m-ou-se

Added [T; N]::zip()

This is my first PR to rust so I hope I have done everything right, or at least close :)

---

This is PR adds the array method `[T; N]::zip()` which, in my mind, is a natural extension to #75212.

My implementation of `zip()` is mostly just a modified copy-paste of `map()`. Should I keep the comments? Also am I right in assuming there should be no way for the `for`-loop to panic, thus no need for the dropguard seen in the `map()`-function?

The doc comment is in a similar way a slightly modified copy paste of [`Iterator::zip()`](https://doc.rust-lang.org/beta/std/iter/trait.Iterator.html#method.zip)

`@jplatte` mentioned in [#75490](https://github.com/rust-lang/rust/pull/75490#issuecomment-677790758) `zip_with()`,
> zip and zip_with seem like they would be useful :)

is this something I should add (assuming there is interest for this PR at all :))

Auto merge of #78242 - Nadrieril:rename-overlapping_endpoints-lint, r=varkor

Rename `overlapping_patterns` lint

As discussed in https://github.com/rust-lang/rust/issues/65477. I also tweaked a few things along the way.

r? `@varkor`
`@rustbot` modify labels: +A-exhaustiveness-checking

Auto merge of #80264 - tmiasko:stdarch, r=Amanieu

Update stdarch submodule

Changes:

* Avx512bw
* Move code out of constify macros

Auto merge of #80208 - bugadani:generics-of-alloc, r=matthewjasper

Reserve necessary space for params in generics_of

Always reserve space for the exact number of generic parameters we need in generics_of. As far as I can see, the default is 0/4 elements based on has_self, and the vector grows on after that.

Auto merge of #79270 - RalfJung:array-repeat-consts, r=oli-obk

Acknowledge that `[CONST; N]` is stable

When `const_in_array_repeat_expressions` (RFC 2203) got unstably implemented as part of https://github.com/rust-lang/rust/pull/61749, accidentally, the special case of repeating a *constant* got stabilized immediately. That is why the following code works on stable:

```rust
const EMPTY: Vec<i32> = Vec::new();

pub const fn bar() -> [Vec<i32>; 2] {
    [EMPTY; 2]
}

fn main() {
    let x = bar();
}
```

In contrast, if we had written `[expr; 2]` for some expression that is not *literally* a constant but could be evaluated at compile-time (e.g. `(EMPTY,).0`), this would have failed.

We could take back this stabilization as it was clearly accidental. However, I propose we instead just officially accept this and stabilize a small subset of RFC 2203, while leaving the more complex case of general expressions that could be evaluated at compile-time unstable. Making that case work well is pretty much blocked on inline `const` expressions (to avoid relying too much on [implicit promotion](https://github.com/rust-lang/const-eval/blob/master/promotion.md)), so it could take a bit until it comes to full fruition. `[CONST; N]` is an uncontroversial subset of this feature that has no semantic ambiguities, does not rely on promotion, and basically provides the full expressive power of RFC 2203 but without the convenience (people have to define constants to repeat them, possibly using associated consts if generics are involved).

Well, I said "no semantic ambiguities", that is only almost true... the one point I am not sure about is `[CONST; 0]`. There are two possible behaviors here: either this is equivalent to `let x = CONST; [x; 0]`, or it is a NOP (if we argue that the constant is never actually instantiated). The difference between the two is that if `CONST` has a destructor, it should run in the former case (but currently doesn't, due to https://github.com/rust-lang/rust/issues/74836); but should not run if it is considered a NOP. For regular `[x; 0]` there seems to be consensus on running drop (there isn't really an alternative); any opinions for the `CONST` special case? Should this instantiate the const only to immediately run its destructors? That seems somewhat silly to me. After all, the `let`-expansion does *not* work in general, for `N > 1`.

Cc `@rust-lang/lang` `@rust-lang/wg-const-eval`
Cc https://github.com/rust-lang/rust/issues/49147

Auto merge of #80205 - tomprogrammer:prettyprint-pattern-mut-binding, r=davidtwco

Fix pretty printing an AST representing `&(mut ident)`

The PR fixes a misguiding help diagnostic in the parser that I reported in #80186. I discovered that the parsers recovery and reporting logic was correct but the pretty printer produced wrong code for the example. (Details in https://github.com/rust-lang/rust/issues/80186#issuecomment-748498676)

Example:
```rust
#![allow(unused_variables)]
fn main() {
    let mut &x = &0;
}
```

The AST fragment

`PatKind::Ref(PatKind::Ident(BindingMode::ByValue(Mutability::Mut), ..), Mutability::Not)`

was printed to be `&mut ident`. But this wouldn't round trip through parsing again, because then it would be:

`PatKind::Ref(PatKind::Ident(BindingMode::ByValue(Mutability::Not), ..), Mutability::Mut)`

Now the pretty-printer prints `&(mut ident)`. Reparsing that code results in the AST fragment

`PatKind::Ref(PatKind::Paren(PatKind::Ident(BindingMode::ByValue(Mutability::Mut), ..)), Mutability::Not)`

which I think should behave like the original pattern.

Old diagnostic:
```
error: `mut` must be attached to each individual binding
 --> src/main.rs:3:9
  |
3 |     let mut &x = &0;
  |         ^^^^^^ help: add `mut` to each binding: `&mut x`
  |
  = note: `mut` may be followed by `variable` and `variable @ pattern`
```

New diagnostic:

```
error: `mut` must be attached to each individual binding
 --> src/main.rs:3:9
  |
3 |     let mut &x = &0;
  |         ^^^^^^ help: add `mut` to each binding: `&(mut x)`
  |
  = note: `mut` may be followed by `variable` and `variable @ pattern`
```

Fixes #80186

Auto merge of #80206 - poliorcetics:rustdoc-default-langstring, r=GuillaumeGomez,jyn514

impl Default for LangString, replacing all_false by default

Fix #80015

`@rustbot` label C-cleanup  T-rustdoc  A-markdown-parsing

Auto merge of #80253 - Dylan-DPC:rollup-bkmn74z, r=Dylan-DPC

Rollup of 11 pull requests

Successful merges:

 - #80159 (Add array search aliases)
 - #80166 (Edit rustc_middle docs)
 - #80170 (Fix ICE when lookup method in trait for type that have bound vars)
 - #80171 (Edit rustc_middle::ty::TyKind docs)
 - #80199 (also const-check FakeRead)
 - #80211 (Handle desugaring in impl trait bound suggestion)
 - #80236 (Use pointer type in AtomicPtr::swap implementation)
 - #80239 (Update Clippy)
 - #80240 (make sure installer only creates directories in DESTDIR)
 - #80244 (Cleanup markdown span handling)
 - #80250 (Minor cleanups in LateResolver)

Failed merges:

r? `@ghost`
`@rustbot` modify labels: rollup

Rollup merge of #80250 - bugadani:resolver-cleanup, r=petrochenkov

Minor cleanups in LateResolver

 - Avoid calculating hash twice
 - Avoid creating a closure in every iteration of a loop
 - Reserve space for path in advance
 - Some readability changes

Rollup merge of #80244 - jyn514:spans, r=bugadani

Cleanup markdown span handling

1. Get rid of `locate()` in markdown handling

This function was unfortunate for several reasons:

- It used `unsafe` because it wanted to tell whether a string came from
  the same *allocation* as another, not just whether it was a textual match.
- It recalculated spans even though they were already available from pulldown
- It sometimes *failed* to calculate the span, which meant it was always possible for the span to be `None`, even though in practice that should never happen.

This has several cleanups:

- Make the span required
- Pass through the span from pulldown in the `HeadingLinks` and `Footnotes` iterators
- Only add iterator bounds on the `impl Iterator`, not on `new` and the struct itself.

2. Remove unnecessary scope in `markdown_links`

I recommend reading a single commit at a time.

cc ``@bugadani`` - this will conflict with https://github.com/rust-lang/rust/pull/77859, I'll try to make sure that gets merged first.

Rollup merge of #80240 - yshui:master, r=Mark-Simulacrum

make sure installer only creates directories in DESTDIR

Fixes #80238

Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>

Rollup merge of #80239 - flip1995:clippyup, r=Manishearth

Update Clippy

Biweekly Clippy update.

r? ``@Manishearth``

Rollup merge of #80236 - tmiasko:atomic-swap, r=oli-obk

Use pointer type in AtomicPtr::swap implementation

Closes #80234.

Rollup merge of #80211 - wabain:async-fn-trait-bound-suggestion, r=petrochenkov

Handle desugaring in impl trait bound suggestion

Fixes #79843.

When an associated type of a generic function parameter needs extra bounds, the diagnostics may suggest replacing an `impl Trait` with a named type parameter so that it can be referenced in the where clause. On stable and nightly, the suggestion can be malformed, for instance transforming:

```rust
async fn run(_: &(), foo: impl Foo) -> std::io::Result<()>
```

Into:

```rust
async fn run(_: &, F: Foo(), foo: F) -> std::io::Result<()> where <F as Foo>::Bar: Send
                 ^^^^^^^^         ^                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^
```

Where we want something like:

```rust
async fn run<F: Foo>(_: &(), foo: F) -> std::io::Result<()> where <F as Foo>::Bar: Send
            ^^^^^^^^              ^                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^
```

The problem is that the elided lifetime of `&()` is added as a generic parameter when desugaring the async fn; the suggestion code sees this as an existing generic parameter and tries to use its span as an anchor to inject `F` into the parameter list. There doesn't seem to be an entirely principled way to check which generic parameters in the HIR were explicitly named in the source, so this commit changes the heuristics when generating the suggestion to only consider type parameters whose spans are contained within the span of the `Generics` when determining how to insert an additional type parameter into the declaration. (And to be safe it also excludes parameters whose spans are marked as originating from desugaring, although that doesn't seem to handle this elided lifetime.)

Rollup merge of #80199 - RalfJung:const-fake, r=oli-obk

also const-check FakeRead

We need to const-check all statements, including `FakeRead`, to avoid issues like https://github.com/rust-lang/rust/issues/77694.

Fixes https://github.com/rust-lang/rust/issues/77694.
r? ``@oli-obk``

Rollup merge of #80171 - pierwill:pierwill-rustcmiddle-tykind, r=lcnr

Edit rustc_middle::ty::TyKind docs

- Add a definition for this enum.
- Fix typo and missing punctuation.
- Spell out "algebraic data type".

Rollup merge of #80170 - ldm0:fixice, r=lcnr

Fix ICE when lookup method in trait for type that have bound vars

Closes #77910

Rollup merge of #80166 - pierwill:pierwill-rustcmiddle-place, r=petrochenkov

Edit rustc_middle docs

Re-word doc comment for rustc_middle::hir::place::Projection.

Also adds:

- Missing end stop punctuation, and
- Documentation links to `rustc_middle::mir::Place`.

Rollup merge of #80159 - jyn514:array, r=m-ou-se

Add array search aliases

Missed this in https://github.com/rust-lang/rust/pull/80068. This one will really fix https://github.com/rust-lang/rust/issues/46075.

The last alias especially I'm a little unsure about - maybe fuzzy search should be fixed in rustdoc instead? Happy to make that change although I'd have to figure out how.

r? ``@m-ou-se`` although cc ``@GuillaumeGomez`` for the search issue.

Auto merge of #80088 - operutka:fix-cmsg-len-uclibc, r=dtolnay

Fix failing build of std on armv5te-unknown-linux-uclibceabi due to missing cmsg_len_zero

I'm getting the following error when trying to build `std` on `armv5te-unknown-linux-uclibceabi`:

```
error[E0425]: cannot find value `cmsg_len_zero` in this scope
   --> /home/operutka/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/sys/unix/ext/net/ancillary.rs:376:47
    |
376 |             let data_len = (*cmsg).cmsg_len - cmsg_len_zero;
    |                                               ^^^^^^^^^^^^^ not found in this scope
```

Obviously, this branch:
```rust
cfg_if::cfg_if! {
    if #[cfg(any(target_os = "android", all(target_os = "linux", target_env = "gnu")))] {
        let cmsg_len_zero = libc::CMSG_LEN(0) as libc::size_t;
    } else if #[cfg(any(
                  target_os = "dragonfly",
                  target_os = "emscripten",
                  target_os = "freebsd",
                  all(target_os = "linux", target_env = "musl",),
                  target_os = "netbsd",
                  target_os = "openbsd",
              ))] {
        let cmsg_len_zero = libc::CMSG_LEN(0) as libc::socklen_t;
    }
}
```

does not cover the case `all(target_os = "linux", target_env = "uclibc")`.

Update stdarch submodule

Move std_path construction into condition

Inline a single-use closure

Create closure outside of the loop

Fix incorrect logic when merging matches

Add missing semicolon

Remove unnecessary cloned

Precompute vector length in smart_resolve_path_fragment

Clean up with_generic_param_rib, avoid double hashing

Remove unnecessary scope

Get rid of `locate()` in markdown handling

This function was unfortunate for several reasons:

- It used `unsafe` because it wanted to tell whether a string came from
  the same *allocation* as another, not just whether it was a textual
  match.
- It recalculated spans even though they were already available from
  pulldown
- It sometimes *failed* to calculate the span, which meant it was always
  possible for the span to be `None`, even though in practice that
  should never happen.

This commit has several cleanups:

- Make the span required
- Pass through the span from pulldown in the `HeadingLinks` and
  `Footnotes` iterators
- Only add iterator bounds on the `impl Iterator`, not on `new` and the
  struct itself.

Auto merge of #78317 - est31:linear_in_impl_count, r=matthewjasper

Turn quadratic time on number of impl blocks into linear time

Previously, if you had a lot of inherent impl blocks on a type like:

```Rust
struct Foo;

impl Foo { fn foo_1() {} }
// ...
impl Foo { fn foo_100_000() {} }
```

The compiler would be very slow at processing it, because
an internal algorithm would run in O(n^2), where n is the number
of impl blocks. Now, we add a new algorithm that allocates but
is faster asymptotically.

Comparing rustc nightly with a local build of rustc as of this PR (results in seconds):

| N | real time before | real time after |
| - | - | - |
| 4_000 | 0.57 | 0.46 |
| 8_000  | 1.31  | 0.84 |
| 16_000  | 3.56 | 1.69 |
| 32_000 | 10.60 | 3.73 |

I've tuned up the numbers to make the effect larger than the startup noise of rustc, but the asymptotic difference should hold for smaller n as well.

Note: current state of the PR omits error messages if there are other errors present already. For now, I'm mainly interested in a perf run to study whether this issue is present at all. Please queue one for this PR. Thanks!

Edit rustc_middle docs

Re-word doc comment for rustc_middle::hir::place::Projection.

Also adds:

- Missing end stop punctuation, and
- Documentation links to `rustc_middle::mir::Place`.

make sure installer only creates directories in DESTDIR

Fixes #80238

Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>

Edit rustc_middle::ty::TyKind docs

- Add a definition for this enum.
- Fix typo and missing punctuation.
- Spell out "algebraic data type".

Auto merge of #74699 - notriddle:fd-non-negative, r=m-ou-se

Mark `-1` as an available niche for file descriptors

Based on discussion from <https://internals.rust-lang.org/t/can-the-standard-library-shrink-option-file/12768>, the file descriptor `-1` is chosen based on the POSIX API designs that use it as a sentinel to report errors. A bigger niche could've been chosen, particularly on Linux, but would not necessarily be portable.

This PR also adds a test case to ensure that the -1 niche (which is kind of hacky and has no obvious test case) works correctly. It requires the "upper" bound, which is actually -1, to be expressed in two's complement.

Move test from compile-fail to ui/binop

Merge commit '4911ab124c481430672a3833b37075e6435ec34d' into clippyup

Auto merge of #6482 - flip1995:rustup, r=flip1995

Rustup

r? `@ghost`

changelog: none

Bump nightly to 2020-12-20

Merge remote-tracking branch 'upstream/master' into rustup

make sure [CONST; N] drops N times

add test that repeating non-Copy constants works

use exhaustive match for checking Rvalue::Repeat

Auto merge of #80213 - jryans:bootstrap-skip-dsymutil, r=nagisa

Skip `dsymutil` by default for compiler bootstrap

`dsymutil` adds time to builds on Apple platforms for no clear benefit, and also makes it more difficult for debuggers to find debug info (which `@pnkfelix` highlighted on [Zulip](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/does.20lldb.20%28or.20gdb%29.20work.20on.20rustc.20on.20Mac.3F/near/220482092)). The compiler currently defaults to running `dsymutil` to preserve its historical default, but when compiling the compiler itself, we skip it by default since we know it's safe to do so in that case.

r? `@nagisa`

Update compiler/rustc_typeck/src/check/op.rs

Co-authored-by: lcnr <bastian_kauschke@hotmail.de>

Fix pretty printing an AST representing `&(mut ident)`

`PatKind::Ref(PatKind::Ident(BindingMode::ByValue(Mutability::Mut), ..), ..)`
is an AST representing `&(mut ident)`. It was errorneously printed as
`&mut ident` which reparsed into a syntactically different AST.

This affected help diagnostics in the parser.

Check that c_int is i32 in FileDesc::new.

Fix ICE on suggesting calling function

Auto merge of #80123 - DrMeepster:maybe_uninit_write_slice, r=RalfJung

Fix memory leak in test "mem::uninit_write_slice_cloned_no_drop"

This fixes #80116. I replaced the `Rc` based method I was using with a type that panics when dropped.

Auto merge of #80163 - jackh726:binder-refactor-part-3, r=lcnr

Make BoundRegion have a kind of BoungRegionKind

Split from #76814

Also includes making `replace_escaping_bound_vars` only return `T`

Going to r? `@lcnr`
Feel free to reassign

Auto merge of #80100 - mark-i-m:pattORns-2, r=petrochenkov

or_patterns: implement :pat edition-specific behavior

cc #54883 `@joshtriplett`

This PR implements the edition-specific behavior of `:pat` wrt or-patterns, as determined by the crater runs and T-lang consensus in https://github.com/rust-lang/rust/issues/54883#issuecomment-745509090.

I believe this can unblock stabilization of or_patterns.

r? `@petrochenkov`

Skip `dsymutil` by default for compiler bootstrap

`dsymutil` adds time to builds on Apple platforms for no clear benefit, and also
makes it more difficult for debuggers to find debug info. The compiler currently
defaults to running `dsymutil` to preserve its historical default, but when
compiling the compiler itself, we skip it by default since we know it's safe to
do so in that case.

Handle desugaring in impl trait bound suggestion

Auto merge of #79635 - lcnr:const-eval-idk, r=oli-obk

const_evaluatable_checked: fix occurs check

fixes #79615

this is kind of a hack because we use `TypeRelation` for both the `Generalizer` and the `ConstInferUnifier` but i am not sure if there is a useful way to disentangle this without unnecessarily duplicating some code.

The error in the added test is kind of unavoidable until we erase the unused substs of `ConstKind::Unevaluated`. We talked a bit about this in the cg lazy norm meeting (https://rust-lang.zulipchat.com/#narrow/stream/260443-project-const-generics/topic/lazy_normalization_consts)

Use pointer type in AtomicPtr::swap implementation

Reserve necessary space for params in generics_of

impl Default for LangString, replacing all_false by default

Auto merge of #6477 - xFrednet:0000-enable-search-with-dashes, r=ebroto

Adapted the website search for better matching

* This adds the ability to search for ids with dashes and spaces in the name.
    * Example: `missing-errors-doc` and `missing errors doc` are now valid aliases for lint names
* It also improves the fuzzy search in the description. This search will now match any lint that where all searched words are inside the description.
    * Example: `doc section` finds two lints in our selection

This was suggested/discussed on [Zulip](https://rust-lang.zulipchat.com/#narrow/stream/257328-clippy/topic/Enable.20lint.20search.20with.20dashes/near/220469464)

### Testing
These changes can be tested locally by:
1. Clone this branch
2. Download the current lint index from the [gh-pages branch](https://github.com/rust-lang/rust-clippy/blob/gh-pages/master/lints.json)
3. Put it next to the `util/gh-pages/index.html` and open the html file. Make sure that it can load the lint data. (Browsers can be a bit iffy when opening a loacl html page and loading data)

### Note
I found that searching only a few characters (< 3) seams slow and deleting one even more as almost every lint description contains them. This also happens in our current [lint list](https://rust-lang.github.io/rust-clippy/master/index.html). We could change the search to only be triggered if the search field contains more than 3 letters to slightly improve performance.

---

changelog: Adapted the website search for better matching

Auto merge of #79473 - m-ou-se:clamp-in-core, r=m-ou-se

Move {f32,f64}::clamp to core.

`clamp` was recently stabilized (tracking issue: https://github.com/rust-lang/rust/issues/44095). But although `Ord::clamp` was added in `core` (because `Ord` is in `core`), the versions for the `f32` and `f64` primitives were added in `std` (together with `floor`, `sin`, etc.), not in `core` (together with `min`, `max`, `from_bits`, etc.).

This change moves them to `core`, such that `clamp` on floats is available in `no_std` programs as well.

Auto merge of #6316 - ThibsG:WrongSelfConventionTraitDef, r=ebroto

Lint also in trait def for `wrong_self_convention`

Extends `wrong_self_convention` to lint also in trait definition.

By the way, I think the `wrong_pub_self_convention` [example](https://github.com/rust-lang/rust-clippy/blob/dd826b4626c00da53f76f00f02f03556803e9cdb/clippy_lints/src/methods/mod.rs#L197) is misleading.
On [playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=32615ab3f6009e7e42cc3754be0ca17f), it fires `wrong_self_convention`, so the example (or the lint maybe?) needs to be reworked.
The difference with `wrong_self_convention` [example](https://github.com/rust-lang/rust-clippy/blob/dd826b4626c00da53f76f00f02f03556803e9cdb/clippy_lints/src/methods/mod.rs#L172) is mainly the `pub` keyword on the method `as_str`, but the lint doesn't use the function visibility as condition to choose which lint to fire (in fact it uses the visibility of the impl item).

fixes: #6307

changelog: Lint `wrong_self_convention` lint in trait def also

also const-check FakeRead

Auto merge of #80104 - Nadrieril:usefulness-merging, r=varkor

Improve and fix diagnostics of exhaustiveness checking

Primarily, this fixes https://github.com/rust-lang/rust/issues/56379. This also fixes incorrect interactions between or-patterns and slice patterns that I discovered while working on #56379. Those two examples show the incorrect diagnostics:

```rust
match &[][..] {
    [true] => {}
    [true // detected as unreachable but that's not true
        | false, ..] => {}
    _ => {}
}
match (true, None) {
    (true, Some(_)) => {}
    (false, Some(true)) => {}
    (true | false, None | Some(true // should be detected as unreachable
                               | false)) => {}
}
```

I did not measure any perf impact. However, I suspect that [`616ba9f`](https://github.com/rust-lang/rust/pull/80104/commits/616ba9f9f7f5845777a36e1a41a515e6c33a8776) should have a negative impact on large or-patterns. I'll see what the perf run says; I have optimization ideas up my sleeve if needed.

EDIT: I initially had a noticeable perf impact that I thought unavoidable. I then proceeded to avoid it x)

r? `@varkor`
`@rustbot` label +A-exhaustiveness-checking

Tweak diagnostics

Adapted the website search for better matching

* Formatting

Auto merge of #80132 - matthewjasper:revert-eval-order, r=nikomatsakis

Revert change to trait evaluation order

This change breaks some code and doesn't appear to enable any new code.

closes #79902

r? `@nikomatsakis`

Auto merge of #6473 - phansch:split-up-ui-test, r=flip1995

UI Tests: Separate suspicious_else_formatting tests

Was briefly looking into https://github.com/rust-lang/rust-clippy/issues/3864 when I saw that the tests could benefit from being in their own file.

---
changelog: none

Auto merge of #79342 - CDirkx:ipaddr-const, r=oli-obk

Stabilize all stable methods of `Ipv4Addr`, `Ipv6Addr` and `IpAddr` as const

This PR stabilizes all currently stable methods of `Ipv4Addr`, `Ipv6Addr` and `IpAddr` as const.
Tracking issue: #76205

`Ipv4Addr` (`const_ipv4`):
 - `octets`
 - `is_loopback`
 - `is_private`
 - `is_link_local`
 - `is_multicast`
 - `is_broadcast`
 - `is_docmentation`
 - `to_ipv6_compatible`
 - `to_ipv6_mapped`

`Ipv6Addr` (`const_ipv6`):
 - `segments`
 - `is_unspecified`
 - `is_loopback`
 - `is_multicast`
 - `to_ipv4`

`IpAddr` (`const_ip`):
 - `is_unspecified`
 - `is_loopback`
 - `is_multicast`

## Motivation
The ip methods seem like prime candidates to be made const: their behavior is defined by an external spec, and based solely on the byte contents of an address. These methods have been made unstable const in the beginning of September, after the necessary const integer arithmetic was stabilized.

There is currently a PR open (#78802) to change the internal representation of `IpAddr{4,6}` from `libc` types to a byte array. This does not have any impact on the constness of the methods.

## Implementation
Most of the stabilizations are straightforward, with the exception of `Ipv6Addr::segments`, which uses the unstable feature `const_fn_transmute`. The code could be rewritten to equivalent stable code, but this leads to worse code generation (#75085).
This is why `segments` gets marked with `#[rustc_allow_const_fn_unstable(const_fn_transmute)]`, like the already const-stable `Ipv6Addr::new`, the justification being that a const-stable alternative implementation exists https://github.com/rust-lang/rust/pull/76206#issuecomment-685044184.

## Future posibilities
This PR const-stabilizes all currently stable ip methods, however there are also a number of unstable methods under the `ip` feature (#27709). These methods are already unstable const. There is a PR open (#76098) to stabilize those methods, which could include const-stabilization. However, stabilizing those methods as const is dependent on `Ipv4Addr::octets` and `Ipv6Addr::segments` (covered by this PR).

implement edition-specific :pat behavior for 2015/18

UI Tests: Separate suspicious_else_formatting tests

Auto merge of #6471 - phansch:fix-bless, r=flip1995

Fix blessing of new reference files

Adding of new reference files wasn't handled correctly. It was trying to
read a file that didn't exist yet.

Instead of unwrapping, we now treat a missing reference file as empty
(`Vec::new`). This makes the following conditional work. We then also
have to re-read the reference file after it was being copied. This
second read is technically the same as in the old shell script, but
wasn't really obvious there. The shell script did a `-s` test which
reads the file as well.

changelog: internal: Fix `cargo dev bless` when new reference files are added

Auto merge of #80106 - jackh726:binder-refactor-part-2, r=lcnr

A lot of refactoring to remove more `Binder::bind`s

Split out from #76814

More rebinds

More rebinds

Fix blessing of new reference files

Adding of new reference files wasn't handled correctly. It was trying to
read a file that didn't exist yet.

Instead of unwrapping, we now treat a missing reference file as empty
(`Vec::new`). This makes the following conditional work. We then also
have to re-read the reference file after it was being copied. This
second read is technically the same as in the old shell script, but
wasn't really obvious. The shell script did a `-s` test which reads the
file.

Auto merge of #6464 - ahouts:make-needless_update-ignore-non_exhaustive-structs, r=phansch

make needless_update ignore non_exhaustive structs

changelog: make `needless_update` lint ignore `non_exhaustive` structs

fixes #6323

Auto merge of #80180 - JohnTitor:rollup-a31s996, r=JohnTitor

Rollup of 7 pull requests

Successful merges:

 - #78083 (Stabilize or_insert_with_key)
 - #79211 (Add the "async" and "promise" doc aliases to `core::future::Future`)
 - #79612 (Switch some links in compiler/ to intra-doc links)
 - #80068 (Add `&mut` as an alias for 'reference' primitive)
 - #80129 (docs: Edit rustc_ast::token::Token)
 - #80133 (Suppress `CONST_ITEM_MUTATION` lint if a dereference occurs anywhere)
 - #80155 (Fix typo)

Failed merges:

r? `@ghost`
`@rustbot` modify labels: rollup

Rollup merge of #80155 - matsujika:matsujika-patch-1, r=jonas-schievink

Fix typo

Rollup merge of #80133 - Aaron1011:fix/const-mut-deref, r=estebank

Suppress `CONST_ITEM_MUTATION` lint if a dereference occurs anywhere

Fixes #79971

Rollup merge of #80129 - pierwill:patch-6, r=estebank

docs: Edit rustc_ast::token::Token

Add missing punctuation.

Rollup merge of #80068 - jyn514:mut-reference, r=m-ou-se

Add `&mut` as an alias for 'reference' primitive

Closes https://github.com/rust-lang/rust/issues/46075.

Rollup merge of #79612 - jyn514:compiler-links, r=Aaron1011

Switch some links in compiler/ to intra-doc links