Luckily it's comparatively simple to just restore the `VecDeque` into a valid state on unwinds.

This way, no other test can be tripped up by `test_shrink_to_unwind` changing the alloc error hook.

Refs: rust-lang#122985

…ue types.

We already handle this case this way on the coherence side, and it matches the new solver's behaviour. While there is some breakage around type-alias-impl-trait (see new "type annotations needed" in tests/ui/type-alias-impl-trait/issue-84660-unsoundness.rs), no stable code breaks, and no new stable code is accepted.

No stable code is affected, as this requires the `trait_upcasting` feature gate.

LLVM component names are not immediately obvious (they usually omit any
suffixes on the target arch name), and if they're incorrect, the test
will silently never run.

Stabilize `LazyCell` and `LazyLock`

Closes rust-lang#109736

This stabilizes the [`LazyLock`](https://doc.rust-lang.org/stable/std/sync/struct.LazyLock.html) and [`LazyCell`](https://doc.rust-lang.org/stable/std/cell/struct.LazyCell.html) types:

```rust
static HASHMAP: LazyLock<HashMap<i32, String>> = LazyLock::new(|| {
    println!("initializing");
    let mut m = HashMap::new();
    m.insert(13, "Spica".to_string());
    m.insert(74, "Hoyten".to_string());
    m
});

let lazy: LazyCell<i32> = LazyCell::new(|| {
    println!("initializing");
    92
});
```

r? libs-api

Fix c_char on AIX

Closes rust-lang#122985

…acrum

Fix `VecDeque::shrink_to` UB when `handle_alloc_error` unwinds.

Fixes rust-lang#123369

For `VecDeque` it's relatively simple to restore the buffer into a consistent state so this PR does just that.

Note that with its current implementation, `shrink_to` may change the internal arrangement of elements in the buffer, so e.g. `[D, <uninit>, A, B, C]` will become `[<uninit>, A, B, C, D]` and `[<uninit>, <uninit>, A, B, C]` may become `[B, C, <uninit>, <uninit>, A]` if `shrink_to` unwinds. This shouldn't be an issue though as we don't make any guarantees about the stability of the internal buffer arrangement (and this case is impossible to hit on stable anyways).

This PR also includes a test with code adapted from rust-lang#123369 which fails without the new `shrink_to` code. Does this suffice or do we maybe need more exhaustive tests like in rust-lang#108475?

cc `@Amanieu`

`@rustbot` label +T-libs

…ompiler-errors

Some unstable changes to where opaque types get defined

None of these can be reached from stable afaict.

r? ``@compiler-errors``

cc rust-lang#116652

…r=jhpratt

Stabilize `div_duration`

Closes rust-lang#63139

tidy: validate LLVM component names in tests

LLVM component names are not immediately obvious (they usually omit any suffixes on the target arch name), and if they're incorrect, the test will silently never run.

This happened [here](rust-lang#125220 (comment)), and it would be nice to prevent it.

Exit the process a short time after entering our ctrl-c handler

Fixes rust-lang#124212

r? `@bjorn3`