It turns out it's never constructed anywhere.

and reexport

Now that VaList, et al. have a module, they only need one `#[unstable]`.

…nostics on local fields

…e_not_in_denylist` API

- r-l/r 126784
- r-l/r 127113
- r-l/miri 3562

…le, r=oli-obk,RalfJung

Support tail calls in mir via `TerminatorKind::TailCall`

This is one of the interesting bits in tail call implementation — MIR support.

This adds a new `TerminatorKind` which represents a tail call:
```rust
    TailCall {
        func: Operand<'tcx>,
        args: Vec<Operand<'tcx>>,
        fn_span: Span,
    },
```

*Structurally* this is very similar to a normal `Call` but is missing a few fields:
- `destination` — tail calls don't write to destination, instead they pass caller's destination to the callee (such that eventual `return` will write to the caller of the function that used tail call)
- `target` — similarly to `destination` tail calls pass the caller's return address to the callee, so there is nothing to do
- `unwind` — I _think_ this is applicable too, although it's a bit confusing
- `call_source` — `become` forbids operators and is not created as a lowering of something else; tail calls always come from HIR (at least for now)

It might be helpful to read the interpreter implementation to understand what `TailCall` means exactly, although I've tried documenting it too.

-----

There are a few `FIXME`-questions still left, ideally we'd be able to answer them during review ':)

-----

r? `@oli-obk`
cc `@scottmcm` `@DrMeepster` `@JakobDegen`

[`macro_metavar_expr_concat`] Add support for literals

Adds support for things like `${concat($variable, 123)}` or `${concat("hello", "_world")}` .

cc rust-lang#124225

…by-fallback-hard-in-2024, r=compiler-errors

Make `NEVER_TYPE_FALLBACK_FLOWING_INTO_UNSAFE` a deny-by-default lint in edition 2024

I don't actually really care about this, but `@traviscross` asked me to do this, because lang team briefly discussed this before.

(TC here:)

Specifically, our original FCPed plan included this step:

- Add a lint against fallback affecting a generic that is passed to an `unsafe` function.
   - Perhaps make this lint `deny-by-default` or a hard error in Rust 2024.

That is, we had left as an open question strengthening this in Rust 2024, and had marked it as an open question on the tracking issue.  We're nominating here to address the open question.  (Closing the remaining open question helps us to fully mark this off for Rust 2024.)

r? `@compiler-errors`

Tracking:

- rust-lang#123748

…Nilstrieb

Give VaList its own home

Just rearranging things internally and reexporting.

rustdoc: Remove OpaqueTy

r? `@ghost`

Apparently this works lol?!?

Run alloc sync tests

I was browsing the code and this struck me as weird. We're not running some doc tests because, the comment says, Windows builders deadlock. That should absolutely not happen, at least with our current implementation. And if it does happen I'd like to know.

Just to be sure though I'll do some try builds.

try-job: x86_64-msvc
try-job: i686-msvc
try-job: i686-mingw
try-job: x86_64-mingw

…r-errors

Use field ident spans directly instead of the full field span in diagnostics on local fields

This improves diagnostics and avoids having to store the `DefId`s of fields

…s-knowable, r=lcnr

Uplift trait ref is knowable into `rustc_next_trait_solver`

Self-explanatory. Eliminates one more delegate method.

r? lcnr cc `@fmease`

…r=lcnr

Uplift elaboration into `rustc_type_ir`

Allows us to deduplicate and consolidate elaboration (including these stupid elaboration duplicate fns i added for pretty printing like 3 years ago) so I'm pretty hyped about this change :3

r? lcnr

…-permutations, r=kobzol

Improve `run-make/output-type-permutations` code and improve `filename_not_in_denylist` API

r? `@Kobzol`

…nting, r=fmease

Fix intrinsic const parameter counting with `effects`

r? project-const-traits

…as_tests, r=aDotInTheVoid

rustdoc-json: add type/trait alias tests

Not sure if this tests everything there is to test in them though.

Updates rust-lang#81359