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 9 pull requests #131511

Merged
merged 25 commits into from
Oct 10, 2024
Merged

Rollup of 9 pull requests #131511

merged 25 commits into from
Oct 10, 2024

Conversation

matthiaskrgr
Copy link
Member

Successful merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

davidtwco and others added 25 commits September 24, 2024 15:42
Enabling a tied feature should not enable the other feature
automatically. This was fixed by something in rust-lang#128796, probably rust-lang#128221
or rust-lang#128679.
`rustc_codegen_llvm` and `rustc_codegen_gcc` duplicated logic for
checking if tied target features were partially enabled. This commit
consolidates these checks into `rustc_codegen_ssa` in the
`codegen_fn_attrs` query, which also is run pre-monomorphisation for
each function, which ensures that this check is run for unused functions,
as would be expected.
LLVM 20 split out what used to be called b16b16 and correspond to aarch64
FEAT_SVE_B16B16 into sve-b16b16 and sme-b16b16.
Add sme-b16b16 as an explicit feature and update the codegen accordingly.
…n, r=wesleywiser

codegen_ssa: consolidate tied target checks

Fixes rust-lang#105110.
Fixes rust-lang#105111.

`rustc_codegen_llvm` and `rustc_codegen_gcc` duplicated logic for checking if tied target features were partially enabled. This PR consolidates these checks into `rustc_codegen_ssa` in the `codegen_fn_attrs` query, which also is run pre-monomorphisation for each function, which ensures that this check is run for unused functions, as would be expected.

Also adds a test confirming that enabling one tied feature doesn't imply another - the appropriate error for this was already being emitted. I did a bisect and narrowed it down to two patches it was likely to be - something in rust-lang#128796, probably rust-lang#128221 or rust-lang#128679.
…, r=workingjubilee

Stabilize const `{slice,array}::from_mut`

This PR stabilizes the following APIs as const stable as of rust `1.83`:
```rs
// core::array
pub const fn from_mut<T>(s: &mut T) -> &mut [T; 1];

// core::slice
pub const fn from_mut<T>(s: &mut T) -> &mut [T];
```
This is made possible by `const_mut_refs` being stabilized (yay).

Tracking issue: rust-lang#90206
rustc_target: Add sme-b16b16 as an explicit aarch64 target feature

LLVM 20 split out what used to be called b16b16 and correspond to aarch64
FEAT_SVE_B16B16 into sve-b16b16 and sme-b16b16.
Add sme-b16b16 as an explicit feature and update the codegen accordingly.

Resolves rust-lang#129894.
…in-traits, r=spastorino

Precise capturing in traits

This PR begins to implement `feature(precise_capturing_in_traits)`, which enables using the `impl Trait + use<..>` syntax for RPITITs. It implements this by giving the desugared GATs variance, and representing the uncaptured lifetimes as bivariant, like how opaque captures work.

Right now, I've left out implementing a necessary extension to the `refining_impl_trait` lint, and also I've made it so that all RPITITs always capture the parameters that come from the trait, because I'm not totally yet convinced that it's sound to not capture these args. It's certainly required to capture the type and const parameters from the trait (e.g. Self), or else users could bivariantly relate two RPITIT args that come from different impls, but region parameters don't affect trait selection in the same way, so it *may* be possible to relax this in the future. Let's stay conservative for now, though.

I'm not totally sure what tests could be added on top of the ones I already added, since we really don't need to exercise the `precise_capturing` feature but simply what makes it special for RPITITs.

r? types

Tracking issue:
* rust-lang#130044
…zkan

Match std `RUSTFLAGS` for host and target for `mir-opt` test suite to fix double std build/rebuilds

Previously the bootstrap compiletest `Step::run` flow had:

```rs
// ensure that `libproc_macro` is available on the host.
builder.ensure(compile::Std::new(compiler, compiler.host));

// ...

if suite == "mir-opt" {
    builder.ensure(compile::Std::new_for_mir_opt_tests(compiler, target));
} else {
    builder.ensure(compile::Std::new(compiler, target));
}
```

This can cause unnecessary std rebuilds (even on the same invocation) because if host == target then `builder.ensure(compile::Std::new_for_mir_opt_tests(compiler, target))` will have different `RUSTFLAGS` than `builder.ensure(compile::Std::new(compiler, compiler.host))`.

This PR fixes that by matching up std `RUSTFLAGS` if the test suite is `mir-opt`:

```rs
if suite == "mir-opt" {
    builder.ensure(compile::Std::new_for_mir_opt_tests(compiler, compiler.host));
} else {
    builder.ensure(compile::Std::new(compiler, compiler.host));
}
```

This is a short-term fix, the better fix is to enforce how `RUSTFLAGS` are handled as described in rust-lang#131437 (comment).

Fixes rust-lang#131437.
…ouxu

add test infra to explicitely test rustc with autodiff/enzyme disabled

I assume this is not what you want for now, but I'll update the PR once I understand how the ignore- directives work.

To summarize the situation, we want a feature gate test where we don't enable the autodiff feature using `#![feature(autodiff)]`. There are two situations.
1) We have a rustc which was build without autodiff support (current default): It gives one error about the feature being needed and one error about this rustc version being build without autodiff support.
2) We have a rustc which was build with autodiff support (i.e. for now a custom build): It gives one error about the feature being needed.

We have a `//`````@needs-enzyme`````` directive which we can use in revisions for the second case.
However, we have no way to specify that needs-enzyme implies that the second error should not be seen.
This ads a way of passing the following test:
```
//@ revisions: has_support no_support
//`````@[has_support]````` needs-enzyme
//`````@[no_support]````` needs-enzyme-disabled

#![crate_type = "lib"]

#[autodiff(dfoo, Reverse)]
//[has_support]~^ ERROR use of unstable library feature 'autodiff' [E0658]
//[no_support]~^^ ERROR use of unstable library feature 'autodiff' [E0658]
//[no_support]~| ERROR this rustc version does not support autodiff
fn foo() {}
```
Cherry picking this PR to my frontend pr makes the test above pass in both configurations (enzyme=true/false in config.toml).
I'm open to other changes that make this testcase pass.

r? `````@jieyouxu`````

Tracking:

- rust-lang#124509
…mpat-2, r=jieyouxu

Compiler & its UI tests: Rename remaining occurrences of "object safe" to "dyn compatible"

Follow-up to rust-lang#130826.
Part of rust-lang#130852.

1. 1st commit: Fix stupid oversights. Should've been part of rust-lang#130826.
2. 2nd commit: Rename the unstable feature `object_safe_for_dispatch` to `dyn_compatible_for_dispatch`. Might not be worth the churn, you decide.
3. 3rd commit: Apply the renaming to all UI tests (contents and paths).
…h, r=jieyouxu

Avoid redundant sysroot additions to `PATH` when linking

Currently, `rustc` prepends `$HOME/.rustup/toolchains/stable-aarch64-apple-darwin/lib/rustlib/aarch64-apple-darwin/bin` to the `PATH` three times before invoking the linker, which is unnecessary, once should be enough.

Spotted this while trying to get `-Clinker-flavor=gcc` and `-Clinker-flavor=ld` closer together, not really important.

`````@rustbot````` A-linkage
@rustbot rustbot added A-meta Area: Issues & PRs about the rust-lang/rust repository itself 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 Oct 10, 2024
@rustbot rustbot added T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue. WG-trait-system-refactor The Rustc Trait System Refactor Initiative (-Znext-solver) rollup A PR which is a rollup labels Oct 10, 2024
@matthiaskrgr
Copy link
Member Author

@bors r+ rollup=never p=9

@bors
Copy link
Contributor

bors commented Oct 10, 2024

📌 Commit 8ddd327 has been approved by matthiaskrgr

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 Oct 10, 2024
@bors
Copy link
Contributor

bors commented Oct 10, 2024

⌛ Testing commit 8ddd327 with merge 52fd998...

@bors
Copy link
Contributor

bors commented Oct 10, 2024

☀️ Test successful - checks-actions
Approved by: matthiaskrgr
Pushing 52fd998 to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Oct 10, 2024
@bors bors merged commit 52fd998 into rust-lang:master Oct 10, 2024
7 checks passed
@rustbot rustbot added this to the 1.83.0 milestone Oct 10, 2024
@rust-timer
Copy link
Collaborator

📌 Perf builds for each rolled up PR:

PR# Message Perf Build Sha
#130308 codegen_ssa: consolidate tied target checks e920f42b72549e3a0b3588b410ebb2e2f57c3423 (link)
#130538 Stabilize const {slice,array}::from_mut d03470d0e483e122fa7657e44d2a8a081b5c3ca8 (link)
#130741 rustc_target: Add sme-b16b16 as an explicit aarch64 target … e65fe98c9556b3b1df387bbae17dcc48c0938865 (link)
#131033 Precise capturing in traits 485c904c1d3fd3444036e18511809df71db6bfb0 (link)
#131442 Match std RUSTFLAGS for host and target for mir-opt tes… d8a4b6741a5e0667b38537b7c605c3642c92d29a (link)
#131470 add test infra to explicitely test rustc with autodiff/enzy… 3d0e994f328abfbb864b8d36ce0c0ac1ef7dd30d (link)
#131475 Compiler & its UI tests: Rename remaining occurrences of "o… 788e88af213c364477f9da869970c30f53b6f7a3 (link)
#131493 Avoid redundant sysroot additions to PATH when linking 1d82626f3bddd9ca874451e5bf42326fd5e19d67 (link)
#131509 Update .mailmap 371c8f9b417270a6a8795e9062baa99ee187dc1b (link)

previous master: d0141af514

In the case of a perf regression, run the following command for each PR you suspect might be the cause: @rust-timer build $SHA

@rust-timer
Copy link
Collaborator

Finished benchmarking commit (52fd998): comparison URL.

Overall result: ✅ improvements - no action needed

@rustbot label: -perf-regression

Instruction count

This is the most reliable metric that we have; it was used to determine the overall result at the top of this comment. However, even this metric can sometimes exhibit noise.

mean range count
Regressions ❌
(primary)
- - 0
Regressions ❌
(secondary)
- - 0
Improvements ✅
(primary)
-0.6% [-0.6%, -0.6%] 1
Improvements ✅
(secondary)
-0.2% [-0.2%, -0.2%] 1
All ❌✅ (primary) -0.6% [-0.6%, -0.6%] 1

Max RSS (memory usage)

Results (primary -2.0%, secondary -0.0%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

mean range count
Regressions ❌
(primary)
- - 0
Regressions ❌
(secondary)
3.0% [3.0%, 3.0%] 1
Improvements ✅
(primary)
-2.0% [-2.0%, -2.0%] 1
Improvements ✅
(secondary)
-1.5% [-2.2%, -0.8%] 2
All ❌✅ (primary) -2.0% [-2.0%, -2.0%] 1

Cycles

This benchmark run did not return any relevant results for this metric.

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 781.528s -> 781.006s (-0.07%)
Artifact size: 331.97 MiB -> 331.97 MiB (-0.00%)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-meta Area: Issues & PRs about the rust-lang/rust repository itself A-testsuite Area: The testsuite used to check the correctness of rustc merged-by-bors This PR was explicitly merged by bors. PG-exploit-mitigations Project group: Exploit mitigations rollup A PR which is a rollup S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. 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-libs Relevant to the library team, which will review and decide on the PR/issue. WG-trait-system-refactor The Rustc Trait System Refactor Initiative (-Znext-solver)
Projects
None yet
Development

Successfully merging this pull request may close these issues.