For a common pattern.

There's a bad pattern matching confusion present in this function.
`_anon` gets assigned to, and then `_anon` is used as an unbound
variable in the pattern, which is unrelated to the first `_anon`.
If the `_anon` didn't start with `_` the compiler would give warnings.

This was introduced in rust-lang#104239.

I have rewritten the function to remove the confusion and preserve the
existing behaviour. This seems safest, because the original intent is
not clear.

Adds a link to the relevant part of The Rust Reference in the eror
message, and suggests a possible fix (replacing the fragment specifier
with :tt in the macro definition).

Fixes typos in the original message.

Signed-off-by: Lena Milizé <[email protected]>

And wrap the link in the diagnostic in angle brackets.

Signed-off-by: Lena Milizé <[email protected]>

This is very dependent on subjectivity and what screen you use,
but this change makes the radio buttons' outer circle less ugly.

This is because I could see the pixels very clearly, thanks to the
very thin line and high contrast. This change makes both less
severe, giving your browser's antialiasing algorithm more to
work with. Since it's thicker, lowering the contrast shouldn't
impact visibility.

Fixes the desktop scrolling weirdness mentioned in
rust-lang#98775 (comment)

As described in the MDN page for this property:

* The current Firefox ESR is 102, and the first Firefox version
  to support this feature is 59.
* The current Chrome version 112, and the first version to support
  this is 63.
* Edge is described as having a minor bug in `none` mode, but we
  use `contain` mode anyway, so it doesn't matter.
* Safari 16, released September 2022, is the last browser to
  add this feature, and is also the oldest version we officially
  support.

Fix typos in compiler

I ran [`typos -w compiler`](https://github.com/crate-ci/typos) to fix typos in the `compiler` directory.

Refs rust-lang#110150

…avior, r=GuillaumeGomez

rustdoc: use CSS `overscroll-behavior` instead of JavaScript

Fixes the desktop scrolling weirdness mentioned in rust-lang#98775 (comment)

Preview: https://notriddle.com/rustdoc-demo-html-3/overscroll-behavior/issue_107918/index.html

As described in the [MDN overscroll-behavior] page:

* The current Firefox ESR is 102, and the first Firefox version to support this feature is 59.
* The current Chrome version 112, and the first version to support this is 63.
* Edge is described as having a minor bug in `none` mode, but we use `contain` mode anyway, so it doesn't matter.
* Safari 16, released September 2022, is the last browser to add this feature, and is also the oldest version we officially support.

[MDN overscroll-behavior]: https://developer.mozilla.org/en-US/docs/Web/CSS/overscroll-behavior

…kh726

Symbol cleanups

r? ```@jackh726```

cc ```@b-naber```

Remove `..` from return type notation

`@nikomatsakis` and I decided that using `..` in the return-type notation syntax is probably overkill.

r? `@eholk` since you reviewed the last one

Since this is piggybacking now totally off of a pre-existing syntax (parenthesized generics), let me know if you need any explanation of the logic here, since it's a bit more complicated now.

…er, r=GuillaumeGomez

rustdoc: make settings radio and checks thicker, less contrast

This is very dependent on subjectivity and what screen you use, but this change makes the radio buttons' outer circle less ugly.

This is because I could see the pixels very clearly, thanks to the very thin line and high contrast. This change makes both less severe, giving your browser's antialiasing algorithm more to work with. Since it's thicker, lowering the contrast shouldn't impact visibility.

## Preview

https://notriddle.com/rustdoc-demo-html-3/pixelated-border/settings.html

## Before

![image](https://user-images.githubusercontent.com/1593513/231274191-143acbea-c433-4fb1-b46d-e5e4fe328d60.png)

## After

![image](https://user-images.githubusercontent.com/1593513/231287415-c1e59fe8-8bf8-489d-b607-95ebb71e4ac5.png)

<details><summary>Original "after" image with 2px border around checked box</summary>

![image](https://user-images.githubusercontent.com/1593513/231274253-8b5011c6-82fb-4396-84d0-47b6bdff2260.png)

</details>

…stic, r=davidtwco

Improve the error message when forwarding a matched fragment to another macro

Adds a link to [Forwarding a matched fragment](https://doc.rust-lang.org/nightly/reference/macros-by-example.html#forwarding-a-matched-fragment) section of the Rust Reference, and suggests a possible fix (using `:tt` instead in the macro definition).

Also removes typos from the original message, it should be `:lifetime` instead of `$lifetime`.

## Motivation

When trying to write a macro which uses a literal in the matcher from the outer macro, like the following one, using a fragment specified that isn't one of `:ident`, `:lifetime`, or `:tt` currently results in a hard to understand message.

```rs
macro_rules! make_t_for_all_tokens {
    ($($name:literal as $variant:expr,)*) => {
        macro_rules! t {
            $(
                ($name) => {
                    $variant
                };
            )*
        }
    };
}

make_t_for_all_tokens! {
    "fn" as Token::Fn,
    "return" as Token::Return,
    "let" as Token::Let,
}

// This creates
//
// macro_rules! t {
//     ("fn") => {
//         Token::Fn
//     };
//     ("return") => {
//         Token::Return
//     };
//     ("let") => {
//         Token::Let
//     };
// }

t!["fn"];
```

### Before

```
error: no rules expected the token `"fn"`
   --> src/main.rs:103:10
    |
32  |         macro_rules! t {
    |         -------------- when calling this macro
...
103 |     t!["fn"];
    |        ^^^^ no rules expected this token in macro call
    |
note: while trying to match `"fn"`
   --> src/main.rs:34:6
    |
34  |                   ($name) => {
    |                    ^^^^^
...
58  | / make_t_for_all_tokens! {
59  | |     "fn" as Token::Fn,
60  | |     "return" as Token::Return,
61  | |     "let" as Token::Let,
62  | | }
    | |_- in this macro invocation
    = note: captured metavariables except for `$tt`, `$ident` and `$lifetime` cannot be compared to other tokens
    = note: this error originates in the macro `make_t_for_all_tokens` (in Nightly builds, run with -Z macro-backtrace for more info)
```

### After

```
error: no rules expected the token `"fn"`
   --> src/main.rs:103:10
    |
32  |         macro_rules! t {
    |         -------------- when calling this macro
...
103 |     t!["fn"];
    |        ^^^^ no rules expected this token in macro call
    |
note: while trying to match `"fn"`
   --> src/main.rs:34:6
    |
34  |                   ($name) => {
    |                    ^^^^^
...
58  | / make_t_for_all_tokens! {
59  | |     "fn" as Token::Fn,
60  | |     "return" as Token::Return,
61  | |     "let" as Token::Let,
62  | | }
    | |_- in this macro invocation
    = note: captured metavariables except for `:tt`, `:ident` and `:lifetime` cannot be compared to other tokens
    = note: see https://doc.rust-lang.org/nightly/reference/macros-by-example.html#forwarding-a-matched-fragment for more information
    = help: try using `:tt` instead in the macro definition
    = note: this error originates in the macro `make_t_for_all_tokens` (in Nightly builds, run with -Z macro-backtrace for more info)
```

## Unresolved questions

- Preferrably the suggestion should be attached to the `$name:literal` part of the outer macro, instead of being in the notes section at the end. But I'm not familiar with how the compiler works at all, and I have no idea how to approach this kind of solution.
- `@Nilstrieb` raised a question that the suggestion of adding `:tt` isn't accurate when there's more than `tt` being matched, for example when the input is an `item`.

…=jackh726

Split out a separate feature gate for impl trait in associated types

in rust-lang#107645 it was decided that we'll take a new route for type alias impl trait. The exact route isn't clear yet, so while I'm working on implementing some of these proposed changes (e.g. in rust-lang#110010) to be able to experiment with them, I will also work on stabilizing another sugar version first: impl trait in associated types. Similarly I'll look into creating feature gates for impl trait in const/static types.

This PR does nothing but split the feature gate, so that you need to enable a different feature gate for

```rust
impl Trait for Type {
    type Assoc = impl SomeTrait;
}
```

than what you need for `type Foo = impl SomeTrait;`

…ertlarsan68

tidy: Issue an error when UI test limits are too high

cc rust-lang#73494
Ensuring the limits are as low as they need to be will make it harder to accidentally add new tests to any large directories