Co-authored-by: Jubilee <46493976+workingjubilee@users.noreply.github.com>

…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.

fixes rust-lang#125189

They are no longer supported by LLVM 19.

Fixes rust-lang#125492

Debug, PartialEq, and Eq are derived for testing purposes.

Fixes: rust-lang#125526

…antiate

…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

…jubilee

use posix_memalign on almost all Unix targets

Seems nice to be able to use a single common codepath for all of them. :) The `libc` crate says this symbol exists for all Unix targets. I did locally do check-builds to ensure this still builds, but I can't really test more than that.

- For redox, I found indications posix_memalign really exists [here](https://gitlab.redox-os.org/redox-os/relibc/-/merge_requests/271)
- For esp-idf, I found indications [here](playable-tech/esp-idf@c5b297a)
- ~~For horizon and vita (these seem to be gaming console OSes? "Horizon OS" also has some hits for a Facebook product but that seems unrelated), they seem to be based on "newlib", where posix_memalign [seems to exist](https://sourceware.org/git/?p=newlib-cygwin.git;a=commitdiff;h=3ba2c39fb2a12cd7332ef16b1b3e3df994f7c6f5).~~ Turns out no, this 20-year-old standard POSIX function is unfortunately [not supported](rust-lang#125271 (comment)) here.

A small diagnostic improvement for dropping_copy_types

For a value `m`  which implements `Copy` trait, `drop(m);` does nothing.
We now suggest user to ignore it by a abstract and general note: `let _ = ...`.
I think we can give a clearer note here: `let _ = m;`

fixes rust-lang#125189

<!--
If this PR is related to an unstable feature or an otherwise tracked effort,
please link to the relevant tracking issue here. If you don't know of a related
tracking issue or there are none, feel free to ignore this.

This PR will get automatically assigned to a reviewer. In case you would like
a specific user to review your work, you can assign it to them by using

    r​? <reviewer name>
-->

Stop using the avx512er and avx512pf x86 target features

They are no longer supported by LLVM 19.

Fixes rust-lang#125492

…low, r=compiler-errors

remove proof tree formatting, make em shallow

Debugging via tracing `RUSTC_LOG=rustc_trait_selection::solve=debug` is now imo slightly more readable then the actual proof tree formatter. Removing everything that's not needed for the `analyse` visitor allows us to remove a bunch of code.

I personally believe that we should continue to use tracing over proof trees for debugging:
- it eagerly prints, allowing us to debug ICEs
- the proof tree builder ends up going out of sync with the actual runtime behavior, which is confusing
- using shallow proof trees is a lot more performant as we frequently do not recurse into all nested goals when using an analyse visitor
- this allows us to clean up the implementation and remove some code

r? `@compiler-errors`

…=jackh726

Don't eagerly monomorphize drop for types that are impossible to instantiate

Self-explanatory title I think

Fixes rust-lang#125509

Structurally resolve before `builtin_index` in EUV

r? lcnr

…onur-ozkan

 bootstrap: support target specific config overrides

Can't find any previous discussion about not supporting this,
so I get it done.

The motivation of this is from <rust-lang#125473 (comment)>.

…ubilee

Add manual Sync impl for ReentrantLockGuard

Fixes: rust-lang#125526
Tracking Issue: rust-lang#121440

this impl is even shown in the summary in the tracking issue, but apparently was forgotten in the actual implementation