This PR adds a suggestion to replace an inexisting field for an
unmentioned field. Given the following code:
```rust
enum Foo {
    Bar { alpha: u8, bravo: u8, charlie: u8 },
}

fn foo(foo: Foo) {
    match foo {
        Foo::Bar {
            alpha,
            beta, // `bravo` miswritten as `beta` here.
            charlie,
        } => todo!(),
    }
}
```
the compiler now emits the error messages below.
```text
error[E0026]: variant `Foo::Bar` does not have a field named `beta`
 --> src/lib.rs:9:13
  |
9 |             beta, // `bravo` miswritten as `beta` here.
  |             ^^^^
  |             |
  |             variant `Foo::Bar` does not have this field
  |             help: `Foo::Bar` has a field named `bravo`: `bravo`
```

Note that this suggestion is available iff the number of inexisting
fields and unmentioned fields are both 1.

When a macro is used in the trailing expression position of a block
(e.g. `fn foo() { my_macro!() }`), we currently parse it as an
expression, rather than a statement. As a result, we ended up
using the `NodeId` of the containing statement as our `lint_node_id`,
even though we don't normally do this for macro calls.

If such a macro expands to an expression with a `#[cfg]` attribute,
then the trailing statement can get removed entirely. This lead to
an ICE, since we were usng the `NodeId` of the expression to emit
a lint.

Ths commit makes us skip updating `lint_node_id` when handling
a macro in trailing expression position. This will cause us to
lint at the closest parent of the macro call.

Previously "trait bounds other than `Sized` on const fn parameters are unstable"
error was used for both trait bounds (<T: Trait>) and trait objects (dyn Trait).
This was pretty confusing.

This patch adds a separeta error for trait objects: "trait objects in const fn
are unstable". The error for trait bounds is otherwise intact.

> add intra doc links
> add a usage example for the os::windows module

…rapped in parentheses

Removed extra spaces in front of commas

…d-for-unmentioned-field, r=estebank

Suggest replacing an inexisting field for an unmentioned field

Fix rust-lang#87938

This PR adds a suggestion to replace an inexisting field for an
unmentioned field. Given the following code:
```rust
enum Foo {
    Bar { alpha: u8, bravo: u8, charlie: u8 },
}

fn foo(foo: Foo) {
    match foo {
        Foo::Bar {
            alpha,
            beta, // `bravo` miswritten as `beta` here.
            charlie,
        } => todo!(),
    }
}
```
the compiler now emits the error messages below.
```text
error[E0026]: variant `Foo::Bar` does not have a field named `beta`
 --> src/lib.rs:9:13
  |
9 |             beta, // `bravo` miswritten as `beta` here.
  |             ^^^^
  |             |
  |             variant `Foo::Bar` does not have this field
  |             help: `Foo::Bar` has a field named `bravo`: `bravo`
```

Note that this suggestion is available iff the number of inexisting
fields and unmentioned fields are both 1.

… r=nagisa

Allow simd_shuffle to accept vectors of any length

cc ``@rust-lang/project-portable-simd`` ``@workingjubilee``

…trochenkov

Check for shadowing issues involving block labels

…trochenkov

Fix linting when trailing macro expands to a trailing semi

When a macro is used in the trailing expression position of a block
(e.g. `fn foo() { my_macro!() }`), we currently parse it as an
expression, rather than a statement. As a result, we ended up
using the `NodeId` of the containing statement as our `lint_node_id`,
even though we don't normally do this for macro calls.

If such a macro expands to an expression with a `#[cfg]` attribute,
then the trailing statement can get removed entirely. This lead to
an ICE, since we were usng the `NodeId` of the expression to emit
a lint.

Ths commit makes us skip updating `lint_node_id` when handling
a macro in trailing expression position. This will cause us to
lint at the closest parent of the macro call.

…=kennytm

fix potential race in AtomicU64 time monotonizer

The AtomicU64-based monotonizer introduced in rust-lang#83093 is incorrect because several threads could try to update the value concurrently and a thread which doesn't have the newest value among all the updates could win.

That bug probably has little real world impact since it doesn't make observed time worse than hardware clocks. The worst case would probably be a thread which has a clock that is behind by several cycles observing several inconsistent fixups, which should be similar to observing the unfiltered backslide in the first place.

New benchmarks, they don't look as good as the original PR but still an improvement compared to the mutex.
I don't know why the contended mutex case is faster now than in the previous benchmarks.

```
actually_monotonic() == true:
test time::tests::instant_contention_01_threads                   ... bench:          44 ns/iter (+/- 0)
test time::tests::instant_contention_02_threads                   ... bench:          45 ns/iter (+/- 0)
test time::tests::instant_contention_04_threads                   ... bench:          45 ns/iter (+/- 0)
test time::tests::instant_contention_08_threads                   ... bench:          45 ns/iter (+/- 0)
test time::tests::instant_contention_16_threads                   ... bench:          46 ns/iter (+/- 0)

atomic u64:
test time::tests::instant_contention_01_threads                   ... bench:          66 ns/iter (+/- 0)
test time::tests::instant_contention_02_threads                   ... bench:         287 ns/iter (+/- 14)
test time::tests::instant_contention_04_threads                   ... bench:         296 ns/iter (+/- 43)
test time::tests::instant_contention_08_threads                   ... bench:         604 ns/iter (+/- 163)
test time::tests::instant_contention_16_threads                   ... bench:       1,147 ns/iter (+/- 29)

mutex:
test time::tests::instant_contention_01_threads                   ... bench:          78 ns/iter (+/- 0)
test time::tests::instant_contention_02_threads                   ... bench:         652 ns/iter (+/- 275)
test time::tests::instant_contention_04_threads                   ... bench:         900 ns/iter (+/- 32)
test time::tests::instant_contention_08_threads                   ... bench:       1,927 ns/iter (+/- 62)
test time::tests::instant_contention_16_threads                   ... bench:       3,748 ns/iter (+/- 146)
```

…_trait_in_const_fn, r=estebank

Add a separate error for `dyn Trait` in `const fn`

Previously "trait bounds other than `Sized` on const fn parameters are unstable" error was used for both trait bounds (`<T: Trait>`) and trait objects (`dyn Trait`). This was pretty confusing.

This PR adds a separate error for trait objects: "trait objects in const fn are unstable". The error for trait bounds is otherwise intact.

This is follow up to rust-lang#88907

r? ``@estebank``

``@rustbot`` label: +A-diagnostics

Add intra-doc links and small changes to `std::os` to be more consistent

I believe that a few items in `std::os` should be linked. I've also added a basic example in `std::os::windows`.

…rivate, r=Mark-Simulacrum

refactor: VecDeques IntoIter fields to private

Made the fields of VecDeque's IntoIter private by creating a IntoIter::from(...) function to create a new instance of IntoIter and migrating usage to use IntoIter::from(...).

…ens, r=wesleywiser

Suggest better place to add call parentheses for method expressions wrapped in parentheses

I wanted to improve the suggestion a bit to both remove the wrapping parentheses **and** add call parentheses by both calling `suggest_method_call` and using `multipart_suggestion`. But I very quickly ran into a problem where multiple overlapping machine applicable suggestions cannot be properly applied together. So I applied the suggestion from the issue and only added the call parentheses directly after the expression.

Fixes: rust-lang#89044

Fix a typo

Removed extra spaces in front of commas