It was accidentally removed in a rebase of https://github.com/rust-lang/rust/pull/62727

Fixes https://github.com/rust-lang/rust/issues/63729

rustc_mir: fix miri substitution/"universe" discipline.

Alternative to #61041, based on @RalfJung's own attempt at it.
I haven't done a full audit, but I believe everything is fixed now.

Fixes #61432.
Closes #61336, as a drive-by fix (for a subset of #43408, that is already special-cased).

r? @oli-obk / @RalfJung cc @varkor @yodaldevoid

Deprecate using rustc_plugin without the rustc_driver dylib.

CC https://github.com/rust-lang/rust/pull/59800, https://github.com/rust-lang/rust/commit/7198687bb2df13a3298ef1e8f594753073d6b9e8

Fix https://github.com/rust-lang/rust/issues/62717

CC https://github.com/rust-lang/rust/pull/59800
https://github.com/rust-lang/rust/commit/7198687bb2df13a3298ef1e8f594753073d6b9e8

Fix https://github.com/rust-lang/rust/issues/62717

Rollup of 5 pull requests

Successful merges:

 - #63252 (Remove recommendation about idiomatic syntax for Arc::clone)
 - #63376 (use different lifetime name for object-lifetime-default elision)
 - #63620 (Use constraint span when lowering associated types)
 - #63699 (Fix suggestion from incorrect `move async` to `async move`.)
 - #63704 ( Fixed: error: unnecessary trailing semicolon)

Failed merges:

r? @ghost

 Fixed: error: unnecessary trailing semicolon

Fix suggestion from incorrect `move async` to `async move`.

PR for #61920. Happy with the test. There must be a better implementation though - possibly a MIR visitor to estabilsh a span that doesn't include the `async` keyword?

Use constraint span when lowering associated types

Fix #63594.

r? @Centril

use different lifetime name for object-lifetime-default elision

Introduce a distinct value for `LifetimeName` to use when this is a object-lifetime-default elision. This allows us to avoid creating incorrect lifetime parameters for the opaque types that result. We really need to overhaul this setup at some point! It's getting increasingly byzantine. But this seems like a relatively... surgical fix.

r? @cramertj

Fixes #62517

Remove recommendation about idiomatic syntax for Arc::clone

I believe we should not make this recommendation. I don't want to argue that `Arc::clone` is less idiomatic than `arc.clone`, but that the choice is not clear cut and that we should not be making this kind of call in the docs.

The `.clone()` form has advantages too: it is more succinct, it is more likely to be understood by beginners, and it is more uniform with other `clone` calls, indeed with most other method calls.

Whichever approach is better, I think that this discussion belongs in a style guide or textbook, rather than the library docs. We don't talk much about idiomatic code in the docs, this place is pretty exceptional.

The recommendation is also not followed in this repo. It is hard to figure out how many calls there are of the `.clone()` form, but there are 1550 uses of `Arc` and only 65 uses of `Arc::clone`. The recommendation has existed for over two years.

The recommendation was added in https://github.com/rust-lang/rust/pull/42137, as a result of https://github.com/rust-lang/rfcs/pull/1954. However, note that that RFC was closed because it was not necessary to change the docs (the original RFC proposed a new function instead). So I don't think an RFC is necessary here (and I'm not trying to re-litigate the discussion on that RFC (which favoured `Arc::clone` as idiomatic) in any case).

cc @nical (who added the docs in the first place; sorry :-) )

r? @alexcrichton (or someone else on @rust-lang/libs )

Currently the default is "inherited" from context, so e.g.  `&impl
Foo<Item = dyn Bar>` would default to `&'x impl Foo<Item = dyn Bar +
'x>`, but this triggers an ICE and is not very consistent.

This patch doesn't implement what I expect would be the correct
semantics, because those are likely too complex. Instead, it handles
what I'd expect to be the common case -- where the trait has no
lifetime parameters.

Object-lifetime-default elision is distinct from other forms of
elision; it always refers to some enclosing lifetime *present in the
surrounding type* (e.g., `&dyn Bar` expands to `&'a (dyn Bar + 'a)`.
If there is no enclosing lifetime, then it expands to `'static`.

Therefore, in an `impl Trait<Item = dyn Bar>` setting, we don't expand
to create a lifetime parameter for the `dyn Bar + 'X` bound.  It will
just be resolved to `'static`.

Annoyingly, the responsibility for this resolution is spread across
multiple bits of code right now (`middle::resolve_lifetimes`,
`lowering`). The lowering code knows that the default is for an object
lifetime, but it doesn't know what the correct result would be.
Probably this should be fixed, but what we do now is a surgical fix:
we have it generate a different result for elided lifetimes in a
object context, and then we can ignore those results when figuring out
the lifetimes that are captured in the opaque type.

Use to Cargo's experimental lockfile format

This commit changes the lock file format of this repository to an
experimental format that isn't rolled out by default in Cargo but is
intended to eventually become the default. The new format moves
information around and compresses the lock file a bit. The intention of
the new format is to reduce the amount of git merge conflicts that
happen in a repository, with rust-lang/rust being a prime candidate for
testing this.

The new format wille ventually become the default but for now it is
off-by-default in Cargo, but Cargo will preserve the format if it sees
it. Since we always build with a beta version of Cargo for the
rust-lang/rust repository it should be safe to go ahead and change the
lock file format here and everyone building this repository will
automatically pick it up.

It's intended that we'll evaluate this lock file format in the
rust-lang/rust repository to see if it reduces the number of perceived
merge conflicts for changes that touch the lock file. This will in turn
help inform the development of the feature in Cargo and whether we
choose to stabilize this and turn it on by default.

Note that this commit does not actually change the contents of the lock
file in terms of a resolution graph, it simply reencodes the lock file
with a new format.

This commit changes the lock file format of this repository to an
experimental format that isn't rolled out by default in Cargo but is
intended to eventually become the default. The new format moves
information around and compresses the lock file a bit. The intention of
the new format is to reduce the amount of git merge conflicts that
happen in a repository, with rust-lang/rust being a prime candidate for
testing this.

The new format wille ventually become the default but for now it is
off-by-default in Cargo, but Cargo will preserve the format if it sees
it. Since we always build with a beta version of Cargo for the
rust-lang/rust repository it should be safe to go ahead and change the
lock file format here and everyone building this repository will
automatically pick it up.

It's intended that we'll evaluate this lock file format in the
rust-lang/rust repository to see if it reduces the number of perceived
merge conflicts for changes that touch the lock file. This will in turn
help inform the development of the feature in Cargo and whether we
choose to stabilize this and turn it on by default.

Note that this commit does not actually change the contents of the lock
file in terms of a resolution graph, it simply reencodes the lock file
with a new format.

fix an ICE

fix method name

Fixed: error: unnecessary trailing semicolon

std: Update `backtrace` crate dependency

This commit updates the `backtrace` crate from 0.3.34 to 0.3.35. The
[included set of changes][changes] for this update mostly includes some
gimli-related improvements (not relevant for the standard library) but
critically includes a fix for rust-lang/backtrace-rs#230. The standard
library will not aqcuire a session-local lock whenever a backtrace is
generated on Windows to allow external synchronization with the
`backtrace` crate itself, allowing `backtrace` to be safely used while
other threads may be panicking.

[changes]: https://github.com/rust-lang/backtrace-rs/compare/0.3.34...0.3.35

This commit updates the `backtrace` crate from 0.3.34 to 0.3.35. The
[included set of changes][changes] for this update mostly includes some
gimli-related improvements (not relevant for the standard library) but
critically includes a fix for rust-lang/backtrace-rs#230. The standard
library will not aqcuire a session-local lock whenever a backtrace is
generated on Windows to allow external synchronization with the
`backtrace` crate itself, allowing `backtrace` to be safely used while
other threads may be panicking.

[changes]: https://github.com/rust-lang/backtrace-rs/compare/0.3.34...0.3.35

Size has a ::zero

Don't special case the `Self` parameter by name

This results in a couple of small diagnostic regressions. They could be avoided by keeping the special case just for diagnostics, but that seems worse.

closes #50125
cc #60869

Change the placement of two functions.

Right now, the order is as follows:
`pop_front()`
`push_front()`
`push_back()`
`pop_back()`

`swap_remove_back()`
`swap_remove_front()`

I believe it would be more natural, and easier to follow, if we place `pop_back()` right after the `pop_front()`, and `swap_remove_back()` after the `swap_remove_front()` like this:
`pop_front()`
`pop_back()`
`push_front()`
`push_back()`

`swap_remove_front()`
`swap_remove_back()`

The rest of the documentation (at least in this module) adheres to the same logic, where the 'front' function always precedes its 'back' equivalent.

Use this to simplify the object safety code a bit.

Improved error message for break in async block

Fixes #63391

Do not generate allocations for zero sized allocations

Alternative to https://github.com/rust-lang/rust/issues/62487

r? @EddyB

There are other places where we could do this, too, but that would cause `static FOO: () = ();` to not have a unique address

Serialize additional data for procedural macros

Split off from #62855

This PR serializes the declaration `Span` and attributes for all
procedural macros. This allows Rustdoc to properly render doc comments
and source links when performing inlinig procedural macros across crates