Signed-off-by: onur-ozkan <[email protected]>

By "actual" we refer to the uplifting logic where we may not compile the requested stage;
instead, we uplift it from the previous stages. Which can lead to bootstrap failures in
specific situations where we request stage X from other steps. However we may end up
uplifting it from stage Y, causing the other stage to fail when attempting to link with
stage X which was never actually built.

Signed-off-by: onur-ozkan <[email protected]>

Before making thread_local accept statements inside the const block,
this test would fail to compile as follows:

    error: no rules expected the token `let`
       --> library/std/tests/thread.rs:26:13
        |
    26  |             let value = 1;
        |             ^^^ no rules expected this token in macro call
        |
    note: while trying to match meta-variable `$init:expr`
       --> library/std/src/thread/local.rs:189:69
        |
    189 |     ($(#[$attr:meta])* $vis:vis static $name:ident: $t:ty = const { $init:expr }; $($rest:tt)*) => (
        |                                                                     ^^^^^^^^^^

…afe`

…tc-crates, r=WaffleLapkin

Undeprecate lint `unstable_features` and make use of it in the compiler

See also rust-lang#117937.

r? compiler

…n,Nilstrieb

Fix deallocation with wrong allocator in (A)Rc::from_box_in

Deallocate the `Box` with the original allocator (via `&A`), not `Global`.

Fixes rust-lang#119749

<details> <summary>Example code with error and Miri output</summary>

(Note that this UB is not observable on stable, because the only usable allocator on stable is `Global` anyway.)

Code ([playground link](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=96193c2c6a1912d7f669fbbe39174b09)):

```rs
#![feature(allocator_api)]
use std::alloc::System;

// uncomment one of these
use std::rc::Rc;
//use std::sync::Arc as Rc;

fn main() {
    let x: Box<[u32], System> = Box::new_in([1,2,3], System);
    let _: Rc<[u32], System> = Rc::from(x);
}
```

Miri output:

```rs
error: Undefined Behavior: deallocating alloc904, which is C heap memory, using Rust heap deallocation operation
   --> /playground/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/alloc/src/alloc.rs:117:14
    |
117 |     unsafe { __rust_dealloc(ptr, layout.size(), layout.align()) }
    |              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ deallocating alloc904, which is C heap memory, using Rust heap deallocation operation
    |
    = help: this indicates a bug in the program: it performed an invalid operation, and caused Undefined Behavior
    = help: see https://doc.rust-lang.org/nightly/reference/behavior-considered-undefined.html for further information
    = note: BACKTRACE:
    = note: inside `std::alloc::dealloc` at /playground/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/alloc/src/alloc.rs:117:14: 117:64
    = note: inside `<std::alloc::Global as std::alloc::Allocator>::deallocate` at /playground/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/alloc/src/alloc.rs:254:22: 254:51
    = note: inside `<std::boxed::Box<std::mem::ManuallyDrop<[u32]>> as std::ops::Drop>::drop` at /playground/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/alloc/src/boxed.rs:1244:17: 1244:66
    = note: inside `std::ptr::drop_in_place::<std::boxed::Box<std::mem::ManuallyDrop<[u32]>>> - shim(Some(std::boxed::Box<std::mem::ManuallyDrop<[u32]>>))` at /playground/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/ptr/mod.rs:507:1: 507:56
    = note: inside `std::mem::drop::<std::boxed::Box<std::mem::ManuallyDrop<[u32]>>>` at /playground/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/mem/mod.rs:992:24: 992:25
    = note: inside `std::rc::Rc::<[u32], std::alloc::System>::from_box_in` at /playground/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/alloc/src/rc.rs:1928:13: 1928:22
    = note: inside `<std::rc::Rc<[u32], std::alloc::System> as std::convert::From<std::boxed::Box<[u32], std::alloc::System>>>::from` at /playground/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/alloc/src/rc.rs:2504:9: 2504:27
note: inside `main`
   --> src/main.rs:10:32
    |
10  |     let _: Rc<[u32], System> = Rc::from(x);
    |                                ^^^^^^^^^^^

note: some details are omitted, run with `MIRIFLAGS=-Zmiri-backtrace=full` for a verbose backtrace

error: aborting due to 1 previous error
```

</details>

…rk-Simulacrum

bootstrap: improvements for compiler builds

Reverted rust-lang#108288 and applied a proper fix with the following commit.

r? `@Mark-Simulacrum`

…ubpats, r=compiler-errors

Report unreachable subpatterns consistently

We weren't reporting unreachable subpatterns in function arguments and `let` expressions. This wasn't very important, but never patterns make it more relevant: a user might write `let (Ok(x) | Err(!)) = ...` in a case where `let Ok(x) = ...` is accepted, so we should report the `Err(!)` as redundant.

r? `@compiler-errors`

…ttern, r=oli-obk

add help message for `exclusive_range_pattern` error

Fixes rust-lang#120047

this error
```
error[E0658]: exclusive range pattern syntax is experimental
 --> src/lib.rs:3:9
  |
3 |         0..42 => {},
  |         ^^^^^
  |
  = note: see issue rust-lang#37854 <rust-lang#37854> for more information
  = help: use an inclusive range pattern, like N..=M
  ```
now includes a help message

Not sure of proper procedure here but this seemed like a good help message (used the one suggested in the original issue), if you have a idea for one that is better or something I missed please comment!

…-errors

`maybe_lint_impl_trait`: separate `is_downgradable` from `is_object_safe`

rust-lang#119752 leveraged and overloaded `is_object_safe` to prevent an ICE, but accurate object safety information is needed for precise suggestions. This separates out `is_downgradable`, used for the ICE prevention, and `is_object_safe`, which returns to its original meaning.

Allow any `const` expression blocks in `thread_local!`

This PR contains a rebase of the macro change from rust-lang#116392, together with adding a test under library/std/tests.

Testing this feature by making the documentation's example code needlessly more complicated was not appropriate as pointed out in rust-lang#116392 (review).

Without the macro change, this new test would fail to build as follows:

```console
error: no rules expected the token `let`
   --> library/std/tests/thread.rs:26:13
    |
26  |             let value = 1;
    |             ^^^ no rules expected this token in macro call
    |
note: while trying to match meta-variable `$init:expr`
   --> library/std/src/thread/local.rs:189:69
    |
189 |     ($(#[$attr:meta])* $vis:vis static $name:ident: $t:ty = const { $init:expr }; $($rest:tt)*) => (
    |                                                                     ^^^^^^^^^^
```

Closes rust-lang#116392.

…time-binders-in-rtn, r=fmease

Don't actually make bound ty/const for RTN

Avoid creating an unnecessary non-lifetime binder when we do RTN on a method that has ty/const params.

Fixes rust-lang#120208

r? oli-obk

Fix -Zremap-path-scope typo

This fixes a documentation typo from rust-lang#115214 where `-Zremap-path-prefix=object` should be `-Zremap-path-scope=object`.

``@rustbot`` label: +F-trim-paths