…w-response, r=lcnr

Clear response values for overflow in new solver

When we have an overflow, return a trivial query response. This fixes an ICE with the code described in rust-lang#110544:

```rust
trait Trait {}

struct W<T>(T);

impl<T, U> Trait for W<(W<T>, W<U>)>
where
    W<T>: Trait,
    W<U>: Trait,
{}

fn impls<T: Trait>() {}

fn main() {
    impls::<W<_>>()
}
```

Where, while proving `W<?0>: Trait`, we overflow but still apply the query response of `?0 = (W<?1>, W<?2>)`. Then while re-processing the query to validate that our evaluation result was stable, we get a different query response that looks like `?1 = (W<?3>, W<?4>), ?2 = (W<?5>, W<?6>)`, and so we trigger the ICE.

Also, by returning a trivial query response we also avoid the infinite-loop/OOM behavior of the old solver.

r? ``@lcnr``

…rk-Simulacrum

Bump libffi-sys to 2.3.0

Bump libffi-sys to 2.3.0 that includes LoongArch support.

Thanks

Related: rust-lang/miri#2858

include source error for LoadLibraryExW

In rust-lang#107595, we added retry behavior for LoadLibraryExW on Windows. If it fails we do not print the underlying error that Windows returned. This made rust-lang#110889 a little harder to debug.

In this PR I am adding the source error in the message if it is available.

… r=cuviper

Make sure that some stdlib method signatures aren't accidental refinements

In the process of implementing https://rust-lang.github.io/rfcs/3245-refined-impls.html, I found a bunch of stdlib implementations that accidentally "refined" their method signatures by dropping  (unnecessary) bounds.

This isn't currently a problem, but may become one if/when method  signature refining is stabilized in the future. Shouldn't hurt to make these signatures a bit more accurate anyways.

NOTE (just to be clear lol): This does not affect behavior at all, since we don't actually take advantage of refined implementations yet!

…-errors

Make drop_flags an IndexVec.

Fixes rust-lang#91943

… r=cjgillot

Don't duplicate anonymous lifetimes for async fn in traits

`record_lifetime_params_for_async` needs to be called outside of the scope of the function, or else it'll end up collecting anonymous lifetimes twice (those on the function and those within the `AnonymousCreateParameter` rib). This matches how `record_lifetime_params_for_async` is being used for functions with bodies below.

This fixes (partially) rust-lang#110963 when the lifetimes are late-bound, but does not do so when the lifetimes are early-bound (as seen from the known-bug that I added).