Fixes #61592

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

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

impl Default for LangString, replacing all_false by default

Fix #80015

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

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

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

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.

make sure installer only creates directories in DESTDIR

Fixes #80238
Signed-off-by: NYuxuan Shui <yshuiv7@gmail.com>

Update Clippy

Biweekly Clippy update.

r? ``@Manishearth``

Use pointer type in AtomicPtr::swap implementation

Closes #80234.

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.)

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``

Edit rustc_middle::ty::TyKind docs

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

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

Closes #77910

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`.

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.

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")`.

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.

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!

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

Also adds:

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

Fixes #80238
Signed-off-by: NYuxuan Shui <yshuiv7@gmail.com>

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

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.

Rustup

r? `@ghost`

changelog: none