Using `!` for `c_void` would have the problem that pointers and
potentially references to an uninhabited type would be created, and at
least for references this is UB.

Also document in addition that newtype wrappers around `c_void` are not
recommended for representing opaque types (as a workaround for `extern
type` not being stable) but instead refer to the Nomicon.

…rent implementation

We need at least two variants of the enum as otherwise the compiler
complains about the #[repr(u8)] attribute and we also need at least one
variant as otherwise the enum would be uninhabitated and dereferencing
pointers to it would be UB.

As such, mark the variants not unstable because they should not actually
exist but because they are temporary implementation details until
`extern type` is stable and can be used instead.

- Cleanup the `impl PartialEq<BookFormat> for Book` implementation
- Implement `impl PartialEq<Book> for BookFormat` so it’s symmetric
  - Fixes rust-lang#53844.
- Removes the last example since it appears to be redundant with the
  previous two examples.

Fixes rust-lang#57306

This may be needed with some host compilers.

Fixes rust-lang#57323

A few items were referenced, but did not have links.

It's simpler and makes some benchmark run up to 1% faster. It also makes
`hir::ExprKind` more like `ast::ExprKind` (which underwent the
equivalent change in rust-lang#55777).

It's identical to `ast::Label`.

Multiple people have asked for them, in
rust-lang#49137.
Given that the unsigned ones already exist,
they are very easy to add and not an additional maintenance burden.

When given multiple lifetimes prior to type parameters in generic
parameters, do not ICE and print the correct suggestion.

Remove confusing comment about ideally using `!` for `c_void`

Using `!` for `c_void` would have the problem that pointers and
potentially references to an uninhabited type would be created, and at
least for references this is UB.

In addition document that newtype wrappers around `c_void` can be used
safely in place of `extern type` until the latter is stabilized.

----

I'm not 100% sure about the usage for opaque types as the [nomicon](https://doc.rust-lang.org/nomicon/ffi.html#representing-opaque-structs) still recommends using `#[repr(C)] pub struct Foo { _private: [u8; 0] }` but it seems like these two should be equivalent in the end? Also the `#[repr(C)]` (in both cases) should be unneeded because such types never being passed by value, never being dereferenced but only passed around as pointer or reference, so the representation of (*values* of) the type itself should not matter at all?

Also in context of `c_void` and `!` the second unresolved question in the [`extern type`](rust-lang#43467) stabilization ticket seems relevant

> In [std's](https://github.com/rust-lang/rust/blob/164619a8cfe6d376d25bd3a6a9a5f2856c8de64d/src/libstd/os/raw.rs#L59-L64) source, it is mentioned that LLVM expects i8* for C's void*.
> We'd need to continue to hack this for the two c_voids in std and libc.
> But perhaps this should be done across-the-board for all extern types?
> Somebody should check what Clang does.

Please correct me if my understanding is wrong and everything's actually fine as is.

…tsakis

Add a regression test for mutating a non-mut #[thread_local]

This should close rust-lang#54901 since the regression has since been fixed.

…acrum

Use correct tracking issue for c_variadic

Fixes rust-lang#57306

…etMisdreavus

Cleanup PartialEq docs.

- Cleanup the `impl PartialEq<BookFormat> for Book` implementation
- Implement `impl PartialEq<Book> for BookFormat` so it’s symmetric
  - Fixes rust-lang#53844.
- Removes the last example since it appears to be redundant with the
  previous two examples.

Support passing cflags/cxxflags/ldflags to LLVM build

This may be needed with some host compilers.

Add signed num::NonZeroI* types

Multiple people have asked for them in rust-lang#49137. Given that the unsigned ones already exist, they are very easy to add and not an additional maintenance burden.

High priority resolutions for associated variants

In rust-lang#56225 variants were assigned lowest priority during name resolution to avoid crater run and potential breakage.

This PR changes the rules to give variants highest priority instead.
Some motivation:
- If variants (and their constructors) are treated as associated items, then they are obviously *inherent* associated items since they don't come from traits.
- Inherent associated items have higher priority during resolution than associated items from traits.
- The reason is that there is a way to disambiguate in favor of trait items (`<Type as Trait>::Ambiguous`), but there's no way to disambiguate in favor of inherent items, so they became unusable in case of ambiguities if they have low priority.
- It's technically problematic to fallback from associated types to anything until lazy normalization (?) is implemented.

Crater found some regressions from this change, but they are all in type positions, e.g.
```rust
fn f() -> Self::Ambiguos { ... } // Variant `Ambiguous` or associated type `Ambiguous`?
```
, so variants are not usable there right now, but they may become usable in the future if rust-lang/rfcs#2593 is accepted.
This PR keeps code like this successfully resolving, but introduces a future-compatibility lint `ambiguous_associated_items` that recommends rewriting it as `<Self as Trait>::Ambiguous`.

resolve: Add a test for issue rust-lang#57539

Add a test for the bugfix regression reported in rust-lang#57539

Closes rust-lang#57539

…enkov

Fix nested `?` matchers

fix rust-lang#57597

I'm not 100% if this works yet...

cc @alercah

When  this is ready (but perhaps not yet):

…avidtwco

Remove an unused function argument

The only use was a debug printing, which might help someone with debugging dataflow problems, but seems otherwise useless

…erister

use structured macro and path resolve suggestions

… r=QuietMisdreavus

Fix sources sidebar not showing up

Fixes rust-lang#57601.

The order of imports made it so that the sidebar creation was called before the sidebar sources were created. Like this, when the sources are loaded, they create the sidebar as expected.

r? @QuietMisdreavus

…reavus

Fixes text becoming invisible when element targetted

Fixes rust-lang#57628.

r? @QuietMisdreavus

privacy: Account for associated existential types

Turns out they *can* be associated (but only in impls, not traits).
Fixes rust-lang#53546 (comment)

r? @arielb1

librustc_metadata: Pass a default value when unwrapping a span

Fixes rust-lang#57323.

When compiling with `static-nobundle` a-la

`rustc -l static-nobundle=nonexistent main.rs`

we now get a neat output in the form of:

```
error[E0658]: kind="static-nobundle" is feature gated (see issue rust-lang#37403)
  |
  = help: add #![feature(static_nobundle)] to the crate attributes to enable

error: aborting due to previous error

For more information about this error, try `rustc --explain E0658`.
```
The build and tests completed successfully on my machine. Should I be adding a new test?

Add some links in std::fs.

A few items were referenced, but did not have links.

…woerister

Two HIR tweaks

Two HIR tweaks that make things slightly simpler and faster.

…xcrichton

Fix release manifest generation

r? @alexcrichton

Document Unpin in std::prelude documentation

…-applicability, r=withoutboats

Enhance `Pin` impl applicability for `PartialEq` and `PartialOrd`.

This allows for comparing for equality or ordering a `Pin<P>` and a `Pin<Q>` as long as `P` and `Q` are correspondingly comparable themselves *even when `P` and `Q` are different types*.
An example might be comparing a `Pin<&mut OsString>` to a `Pin<&mut PathBuf>`, which might arise from pin projections from a pair of larger contexts that aren't `Unpin`.

Fix typo bug in DepGraph::try_mark_green().

r? @Zoxc

Fixes rust-lang#57692.

Fix suggestions given mulitple bad lifetimes

When given multiple lifetimes prior to type parameters in generic
parameters, do not ICE and print the correct suggestion.

r? @estebank

CC @pnkfelix

Fixes: rust-lang#57521