Rollup of 9 pull requests #131511
Merged
Rollup of 9 pull requests #131511
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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
Update .mailmap r? `@aDotInTheVoid`
rustbot
added
A-meta
rustbot
added
T-compiler
|
@bors r+ rollup=never p=9 |
bors
added
S-waiting-on-bors
|
☀️ Test successful - checks-actions |
|
📌 Perf builds for each rolled up PR:
previous master: d0141af514 In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
This was referenced Oct 10, 2024
Open
|
Finished benchmarking commit (52fd998): comparison URL. Overall result: ✅ improvements - no action needed@rustbot label: -perf-regression Instruction countThis 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.
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.
CyclesThis benchmark run did not return any relevant results for this metric. Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 781.528s -> 781.006s (-0.07%) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Successful merges:
{slice,array}::from_mut#130538 (Stabilize const{slice,array}::from_mut)RUSTFLAGSfor host and target formir-opttest suite to fix double std build/rebuilds #131442 (Match stdRUSTFLAGSfor host and target formir-opttest suite to fix double std build/rebuilds)PATHwhen linking #131493 (Avoid redundant sysroot additions toPATHwhen linking)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup