This test was failing under new-symbol-mangling = true. Adapt pattern to
work in both cases.

Related to rust-lang#106002 from December.

…ed type's param-env

I went over the cases where sort_by is used and in these two,
one can use sort_by_key instead.

…it-to-assoc-ty

…r-errors

Remove box expressions from HIR

After rust-lang#108516, `#[rustc_box]` is used at HIR->THIR lowering and this is no longer emitted, so it can be removed.

This is based on top of rust-lang#108471 to help with conflicts, so 43490488ccacd1a822e9c621f5ed6fca99959a0b is the only relevant commit (sorry for all the duplicated pings!)

```@rustbot``` label +S-blocked

…r=jyn514

Prevent stable `libtest` from supporting `-Zunstable-options`

Took a while for me to get around to this but seems trivial (unless I'm missing some reason this will break all our tests). Fixes rust-lang#75526

Basically `libtest` already tries to handle this in https://github.com/rust-lang/rust/blob/501ad021b9a4fb2cd6a39e0302d22f169f6166b0/library/test/src/cli.rs#L310-L318

But that env var was not passed. I'm guessing at one point [this code](https://github.com/rust-lang/rust/blob/501ad021b9a4fb2cd6a39e0302d22f169f6166b0/src/bootstrap/compile.rs#L842-L844) (or a common ancestor) was used to compile the standard library/libtest, but that is no longer the case (or perhaps it never worked, I don't have time to go digging).

I don't love that this is a "allow unstable by default" situation, as it means things like [`rustc-build-sysroot`](https://github.com/RalfJung/rustc-build-sysroot) could accidentally get unstable (CC ```@RalfJung)``` even if this is fixed here, but it's consistent with what happens in `rustc_feature`, so... yeah.

This is user-facing after all, even if it's hard to imagine the outcome of that conversation being "lets continue allowing use of `-Zunstable-features` from stable rust" (especially since a `RUSTC_BOOTSTRAP=1`-shaped loophole remains)... I think it probably should get a vibe check in the t-libs meeting (and plausibly a relnote along the lines of "hey `cargo test -- -Zunstable-options --some --unstable --stuff=here` used to work on stable, that's been fixed, sorry").

I'll nominate it for that after CI comes up green (I've done a smoke check but don't know what (if anything) will need `bootstrap` to enable `RUSTC_BOOTSTRAP=1` when running tests)

r? ```@jyn514```

…arget, r=tmandry

Fix riscv64 fuchsia LLVM target name

Currently, riscv64gc-unknown-fuchsia (added in rust-lang#108722) sets riscv64*gc*-unknown-fuchsia as the LLVM target.

https://github.com/rust-lang/rust/blob/1716932743a7b3705cbf0c34db0c4e070ed1930d/compiler/rustc_target/src/spec/riscv64gc_unknown_fuchsia.rs#L5

However, riscv64*gc*-\* is not a valid LLVM target and causes the following error.

```console
$ rustc --print cfg --target riscv64gc-unknown-fuchsia
error: could not create LLVM TargetMachine for triple: riscv64gc-unknown-fuchsia: No available targets are compatible with triple "riscv64gc-unknown-fuchsia"
```

As with other RISC-V targets, the LLVM target should use riscv64-\*, not riscv64*gc*-\*.

https://github.com/rust-lang/rust/blob/1716932743a7b3705cbf0c34db0c4e070ed1930d/compiler/rustc_target/src/spec/riscv64gc_unknown_freebsd.rs#L5
https://github.com/rust-lang/rust/blob/1716932743a7b3705cbf0c34db0c4e070ed1930d/compiler/rustc_target/src/spec/riscv64gc_unknown_linux_gnu.rs#L5

I confirmed that riscv64-unknown-fuchsia is recognized as a valid LLVM target by using custom targets.

```console
# create a custom target with `"llvm-target": "riscv64-unknown-fuchsia" from no-std riscv64gc target.
$ rustc --print target-spec-json -Z unstable-options --target riscv64gc-unknown-none-elf | grep -v is-builtin | sed 's/"llvm-target".*/"llvm-target": "riscv64-unknown-fuchsia",/' > riscv64gc-unknown-fuchsia.json

$ rustc --print cfg --target riscv64gc-unknown-fuchsia.json
debug_assertions
panic="abort"
target_abi=""
target_arch="riscv64"
target_endian="little"
target_env=""
target_feature="a"
target_feature="c"
target_feature="d"
target_feature="f"
target_feature="m"
...

$ cat riscv64gc-unknown-fuchsia.json
{
  "arch": "riscv64",
  "code-model": "medium",
  "cpu": "generic-rv64",
  "data-layout": "e-m:e-p:64:64-i64:64-i128:128-n32:64-S128",
  "eh-frame-header": false,
  "emit-debug-gdb-scripts": false,
  "features": "+m,+a,+f,+d,+c",
  "linker": "rust-lld",
  "linker-flavor": "ld.lld",
  "llvm-abiname": "lp64d",
  "llvm-target": "riscv64-unknown-fuchsia",
  "max-atomic-width": 64,
  "panic-strategy": "abort",
  "relocation-model": "static",
  "supported-sanitizers": [
    "kernel-address"
  ],
  "target-pointer-width": "64"
}

# Check the current master's LLVM target name causes an error
$ sed -i 's/riscv64-unknown-fuchsia/riscv64gc-unknown-fuchsia/' riscv64gc-unknown-fuchsia.json
$ rustc --print cfg --target riscv64gc-unknown-fuchsia.json
error: could not create LLVM TargetMachine for triple: riscv64gc-unknown-fuchsia: No available targets are compatible with triple "riscv64gc-unknown-fuchsia"
```

r? ```@tmandry```

…henkov

Fix linker detection for clang with prefix

rust-lang#106489 removed check for clang with prefix. It says:

> Also remove the check for -clang, since there are no architecture specific variants of clang (to my knowledge).

However, when doing cross-compilation, a wrapper script for clang with the target name as a prefix is sometimes used.

https://github.com/rust-lang/rust/blob/1716932743a7b3705cbf0c34db0c4e070ed1930d/src/ci/docker/host-x86_64/dist-various-2/Dockerfile#L62

https://github.com/rust-lang/rust/blob/1716932743a7b3705cbf0c34db0c4e070ed1930d/src/ci/docker/scripts/freebsd-toolchain.sh#L76-L80

https://github.com/rust-lang/rust/blob/1716932743a7b3705cbf0c34db0c4e070ed1930d/src/ci/docker/host-x86_64/dist-various-2/Dockerfile#L40

https://github.com/rust-lang/rust/blob/1716932743a7b3705cbf0c34db0c4e070ed1930d/compiler/rustc_target/src/spec/aarch64_pc_windows_gnullvm.rs#L7

It seems the regression did not occur on the targets mentioned above because the default linker flavor is gcc, but it did occur on targets where the default linker flavor is not gcc (taiki-e/setup-cross-toolchain-action@fd352f3).

r? ```@petrochenkov```

…, r=Nilstrieb

inherit_overflow: adapt pattern to also work with v0 mangling

This test was failing under new-symbol-mangling = true. Adapt pattern to work in both cases.

Related to rust-lang#106002 from December.

…-body, r=spastorino

Install projection from RPITIT to default trait method opaque correctly

1. For new lowering strategy `-Zlower-impl-trait-in-trait-to-assoc-ty`, install the correct default trait method projection predicates (RPITIT -> opaque). This makes default trait body tests pass!

2. Fix two WF-checking bugs -- first, we want to make sure that we're always looking for an opaque type in `check_return_position_impl_trait_in_trait_bounds`. That's because the RPITIT projections are normalized to opaques during wfcheck. Second, fix RPITIT's param-envs by not adding the projection predicates that we install on trait methods to make default RPITITs work -- I left a comment why.

3. Also, just a small drive-by for `rustc_on_unimplemented`. Not sure if it affects any tests, but can't hurt.

r? ```@spastorino,``` based off of rust-lang#109140

Use sort_by_key instead of sort_by

I went over the cases where sort_by is used and in these two, one can use sort_by_key instead.

…ddle

Fix invalid markdown link references

Fixes invalid link references in librustdoc's template documentation.
`[text](link)` was interpreted as a relative path to the file, making the link invalid, while `[text][label]` references a label defined in the file itself: <https://www.markdownguide.org/basic-syntax/#reference-style-links>

…er-errors

Fix generics mismatch errors for RPITITs on -Zlower-impl-trait-in-trait-to-assoc-ty

This PR stops reporting errors due to different count of generics on the new synthesized associated types for RPITITs. Those were already reported when we compare the function on the triat with the function on the impl.

r? `@compiler-errors`