…8 is applied

also make it fail if there's a compression issue

zlib is seemingly always enabled, so we can test it unconditionally

it now checks zlib and zstd, via rustc and rust-lld

move it where it's used, and name it like the other scripts

…ing Future bound

…-stack-sanitizer, r=tmandry

Unconditionally allow shadow call-stack sanitizer for AArch64

It is possible to do so whenever `-Z fixed-x18` is applied.

cc `@Darksonn` for context

The reasoning is that, as soon as reservation on `x18` is forced through the flag `fixed-x18`, on AArch64 the option to instrument with [Shadow Call Stack sanitizer](https://clang.llvm.org/docs/ShadowCallStack.html) is then applicable regardless of the target configuration.

At the every least, we would like to relax the restriction on specifically `aarch64-unknonw-none`. For this option, we can include a documentation change saying that users of compiled objects need to ensure that they are linked to runtime with Shadow Call Stack instrumentation support.

Related: rust-lang#121972

…, r=Veykril

rust-analyzer: use in-tree `pattern_analysis` crate

r? `@Veykril`

More work on `zstd` compression

r? `@Kobzol` as we've discussed this.

This is a draft to show the current approach of supporting zstd in compiletest, and making the tests using it unconditional.

Knowing whether llvm/lld was built with `LLVM_ENABLE_ZSTD` is quite hard, so there are two strategies. There are details in the code, and we can discuss this approach. Until we know the config used to build CI artifacts, it seems our options are somewhat limited in any case.

zlib compression seems always enabled, so we only check this in its dedicated test, allowing the test to ignore errors due to zstd not being supported.

The zstd test is made unconditional in what it tests, by relying on `needs-llvm-zstd` to be ignored when `llvm.libzstd` isn't enabled in `config.toml`.

try-job: x86_64-gnu

…c-closure-inference, r=lcnr

Infer async closure args from `Fn` bound even if there is no corresponding `Future` bound on return

In rust-lang#127482, I implemented the functionality to infer an async closure signature when passed into a function that has `Fn` + `Future` where clauses that look like:

```
fn whatever(callback: F)
where
  F: Fn(Arg) -> Fut,
  Fut: Future<Output = Out>,
```

However, rust-lang#127781 demonstrates that this is still incomplete to address the cases users care about. So let's not bail when we fail to find a `Future` bound, and try our best to just use the args from the `Fn` bound if we find it. This is *fine* since most users of closures only really care about the *argument* types for inference guidance, since we require the receiver of a `.` method call to be known in order to probe methods.

When I experimented with programmatically rewriting `|| async {}` to `async || {}` in rust-lang#127827, this also seems to have fixed ~5000 regressions (probably all coming from usages `TryFuture`/`TryStream` from futures-rs): the [before](rust-lang#127827 (comment)) and [after](rust-lang#127827 (comment)) crater runs.

Fixes rust-lang#127781.

…-ref, r=lcnr

Fix projections when parent capture is by-ref but child capture is by-value in the `ByMoveBody` pass

This fixes a somewhat strange bug where we build the incorrect MIR in rust-lang#129074. This one is weird, but I don't expect it to actually matter in practice since it almost certainly results in a move error in borrowck. However, let's not ICE.

Given the code:

```
#![feature(async_closure)]

// NOT copy.
struct Ty;

fn hello(x: &Ty) {
    let c = async || {
        *x;
        //~^ ERROR cannot move out of `*x` which is behind a shared reference
    };
}

fn main() {}
```

The parent coroutine-closure captures `x: &Ty` by-ref, resulting in an upvar of `&&Ty`. The child coroutine captures `x` by-value, resulting in an upvar of `&Ty`. When constructing the by-move body for the coroutine-closure, we weren't applying an additional deref projection to convert the parent capture into the child capture, resulting in an type error in assignment, which is a validation ICE.

As I said above, this only occurs (AFAICT) in code that eventually results in an error, because it is only triggered by HIR that attempts to move a non-copy value out of a ref. This doesn't occur if `Ty` is `Copy`, since we'd instead capture `x` by-ref in the child coroutine.

Fixes rust-lang#129074

…=jieyouxu

Remove redundant type ops: `Eq`/`Subtype`

r? lcnr or anyone really

…ustdoc-output-methods, r=Kobzol

Remove duplicated `Rustdoc::output` method from `run-make-support` lib

I discovered recently that `--output` is deprecated in rustdoc and that `--out-dir` is doing the exact same thing. To keep things along with the current rustdoc status, I removed the `Rustdoc::output` method.

cc `@jieyouxu`
r? `@Kobzol`

…llaumeGomez

rustdoc-json: Use FxHashMap from rustdoc_json_types

Alternative to rust-lang#110051 and rust-lang#127456.

This lets us avoid rehashing the json index after building it by using the same hashmap type in construction and in rustdoc_json_types. The above PR's tried to do this by having rustdoc_json_types get the same hashmap that rustdoc has via rustc_data_structures. However, this can be made simpler if we change rustdoc instead.

For the rustdoc-type republish on crates.io, It will filter out the `pub use`, and not change source at all. rust-lang/rustdoc-types#30. That code [already replaces the hashmap](https://github.com/aDotInTheVoid/rustdoc-types/blob/8d6528669ec64c2af43d1c79a228b7711cefdad7/update.sh#L11) to use the one in `std::collections` (instead of `FxHashMap`)

try-job: dist-arm-linux

r? `@GuillaumeGomez`