Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rollup of 8 pull requests #129126

Closed
wants to merge 24 commits into from

Conversation

GuillaumeGomez
Copy link
Member

Successful merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

dingxiangfei2009 and others added 24 commits August 9, 2024 19:35
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
…-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`
@rustbot rustbot added A-run-make Area: port run-make Makefiles to rmake.rs A-rustdoc-json Area: Rustdoc JSON backend A-testsuite Area: The testsuite used to check the correctness of rustc PG-exploit-mitigations Project group: Exploit mitigations S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) labels Aug 15, 2024
@rustbot rustbot added T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-infra Relevant to the infrastructure team, which will review and decide on the PR/issue. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. rollup A PR which is a rollup labels Aug 15, 2024
@GuillaumeGomez
Copy link
Member Author

@bors r+ p=5 rollup=never

@bors
Copy link
Contributor

bors commented Aug 15, 2024

📌 Commit 38c9f38 has been approved by GuillaumeGomez

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Aug 15, 2024
bors added a commit to rust-lang-ci/rust that referenced this pull request Aug 15, 2024
…llaumeGomez

Rollup of 8 pull requests

Successful merges:

 - rust-lang#128348 (Unconditionally allow shadow call-stack sanitizer for AArch64)
 - rust-lang#128922 (rust-analyzer: use in-tree `pattern_analysis` crate)
 - rust-lang#128935 (More work on `zstd` compression)
 - rust-lang#129072 (Infer async closure args from `Fn` bound even if there is no corresponding `Future` bound on return)
 - rust-lang#129101 (Fix projections when parent capture is by-ref but child capture is by-value in the `ByMoveBody` pass)
 - rust-lang#129106 (Remove redundant type ops: `Eq`/`Subtype`)
 - rust-lang#129122 (Remove duplicated `Rustdoc::output` method from `run-make-support` lib)
 - rust-lang#129124 (rustdoc-json: Use FxHashMap from rustdoc_json_types)

r? `@ghost`
`@rustbot` modify labels: rollup
@bors
Copy link
Contributor

bors commented Aug 15, 2024

⌛ Testing commit 38c9f38 with merge ed311ef...

@rust-log-analyzer
Copy link
Collaborator

The job x86_64-gnu failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)

@bors
Copy link
Contributor

bors commented Aug 15, 2024

💔 Test failed - checks-actions

@bors bors added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Aug 15, 2024
@GuillaumeGomez GuillaumeGomez deleted the rollup-abnvlgj branch August 15, 2024 16:52
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-run-make Area: port run-make Makefiles to rmake.rs A-rustdoc-json Area: Rustdoc JSON backend A-testsuite Area: The testsuite used to check the correctness of rustc PG-exploit-mitigations Project group: Exploit mitigations rollup A PR which is a rollup S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-infra Relevant to the infrastructure team, which will review and decide on the PR/issue. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants