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

fixes rust-lang#125189

They are no longer supported by LLVM 19.

Fixes rust-lang#125492

Fixes: rust-lang#125526

…antiate

…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

…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