Rollup of 12 pull requests#158963
Closed
JonathanBrouwer wants to merge 43 commits into
Closed
Conversation
…pported (windows, unix, uefi, etc.); modified the Unix implementation to use fchmodat instead of open + fchmod; clarified documentations for set_permissions_nofollow; added a test case for set_permissions_nofollow
…st from delegation parent
For small repr(C) aggregates with padding, direct constant
initialization can still lower into field-wise construction plus
memcpy. That leaves the backend to rediscover that the whole object
is a single constant byte pattern.
This is especially visible for non-zero constant aggregates. Instead
of materializing them as separate field stores, we want codegen_ssa to
emit the packed value directly. For example, a value like
InnerPadded { a: 0, b: 1, c: 0 }
can otherwise lower to something like
store i16 0, ptr %val, align 4
store i8 1, ptr %val_plus_2, align 2
store i32 0, ptr %val_plus_4, align 4
call void @llvm.memcpy(..., ptr %val, ...)
while this change produces
store i64 65536, ptr %val, align 4
call void @llvm.memcpy(..., ptr %val, ...)
Why not solve this in LLVM?
At the problematic lowering point, rustc still knows that the MIR
aggregate is small and fully constant. LLVM only sees a lowered stack
temporary built from per-field stores and then copied out. Recovering
that packed constant there would require rediscovering front-end
aggregate semantics after lowering, so emitting the packed store in
rustc is the simpler and more local fix.
Why not keep the previous typed-copy approach?
An earlier approach zeroed padding on typed copies whose source could
be traced back to a constant assignment. That helped some cases, but it
also widened the optimization to runtime copy paths and could introduce
extra runtime stores purely to maintain padding knowledge. That is not
an acceptable tradeoff here.
Keep the scope narrow instead: only handle direct MIR aggregates whose
fields are all constants, and pack them according to the target
endianness before emitting a single integer store.
Add a focused codegen test covering the original PR 157690 entry
points together with non-zero constant cases. The test uses
-Cno-prepopulate-passes so it checks the immediate-store shape directly
at rustc codegen time, instead of depending on later LLVM store
merging.
This prints generics parameters when these are concrete Adt generics args. A lint is emitted we try to format a generic that is found anywhere. Moreover, generics parameters that are ty infer vars are no longer displayed "as-is", it is not clear and might be confusing, in this specific case the name of the generic parameter will be displayed instead.
Co-Authored-By: Clar Fon <15850505+clarfonthey@users.noreply.github.com>
Co-Authored-By: Clar Fon <15850505+clarfonthey@users.noreply.github.com>
Moves unsafe code from `alloc::io` into `alloc::vec`. A more general `try_extend_from_slice` may be useful in the future, but that requires changing how specialization is done for `SpecExtend` and that's a lot for an internal-only function.
* attempt to run parallel CI * fix `tests/rustdoc-ui/doctest/no-capture.rs` fail by setting `RUST_TEST_THREADS=1` for ui tests only * more efficient implementation There are two limitations though for the thread count to work properly: 1. The machine is not performing any other tasks 2. It has only efficiency cores Anyway, it's up to the infra team to decide if this design is ok * small adjustments * fix: make sure `RUST_TEST_THREADS >= 1`
… r=clubby789 Do not build the compiler when invoking `x perf compare` It's wasteful, and can interfere e.g. with workflows where you use `--keep-stage 1` to avoid rebuilding the standard library. If you forgot to specify that flag and use `x perf compare`, it would go build the standard library, which doesn't really make sense. That doesn't happen anymore with this PR.
Library support for aarch64-unknown-linux-pauthtest target This is a follow up to rust-lang#155722, adding library support for the target.
…eyouxu CI job for parallel frontend ui tests ## Summary Part of rust-lang/compiler-team#1005. Supersedes rust-lang#157705. ### Initial setup in this PR For the initial setup in this PR, we'll go ahead with the following combination: - `RUST_TEST_THREADS`: `max(1, $(nproc) // ${PARALLEL_FRONTEND_THREADS})` - `--parallel-frontend-threads`: **4** - `--iteration-count`: **2** Against `./x test tests/ui --stage=2` only. We can tune these knobs in follow-ups. In try jobs we ran, this should not exceed the current longest auto job duration (at around 3h 15m). ## Additional context ### Issues with the previous attempt The issue with the original change was arguments `--parallel-frontend-threads=4 --iteration-count=2` being compiletest-only. They were being passed to other parts of the test harness (e.g. libtest) as is. These parts, however, have no clue of the arguments, hence the errors. I've spent a lot of time on this and haven't found any reasonable way to fix this behavior. We could make bootstrap aware of these specific two arguments and have an additional internal logic for handling this. It's big of a hack, i reckon. The best decision i arrived at is to split testing into two parts: one for compiletest only and another for everything else. The issue is (AFAIK) we can't tell bootstrap (or x.py, at least) to "test the default stuff, but only for compiletest". When used like `x test tests/` it runs _all_ the tests in this directory, including non-default ones, and crashes as it can't find nodejs for doctests. `--skip compiler/ --skip library/ --skip src/tools/ --skip tests/incremental ...` is still not exhaustive list of exclusions. I went on with a whitelist instead of a blacklist. But we, again, can't tell what tests are "default". There's a mechanism in [bootstrap::core::builder::Builder](https://doc.rust-lang.org/nightly/nightly-rustc/bootstrap/core/builder/struct.Builder.html#structfield.log_cli_step_for_tests) for showing "dry-run" test suites, but it's not available from the cli. For now, my whitelist is quite small and i have no idea what should it be like. r? @petrochenkov --- try-job: optional-x86_64-gnu-parallel-frontend
…_arguments, r=mejrs Improve generic parameters handling for #[diagnostic::on_const] cc rust-lang#155570 This Improves generic parameters handling for #[diagnostic::on_const] This is done by printing generics parameters when these are concrete Adt generics args. A lint is emitted we try to format a generic that is found anywhere. Moreover, generics parameters that are ty infer vars are no longer displayed "as-is", it is not clear and might be confusing, in this specific case the name of the generic parameter will be displayed instead. I will need some help for displaying the `Z`parameter correctly. From what I have understood, it is an `ty::Infer(ty::TyVar(_))` that is not correctly displayed via `self.tcx.short_string()` (in `on_unimplemented_components()`), or even not correctly inferred via `self.infcx.ty_to_string()`. EDIT: general descrition updated
…tes-ice, r=BoxyUwU delegation: do not always inherit `ConstArgHasType` predicates The explanation can be found in comment in `inherit_predicates_for_delegation_item`. So the problem is that we have two `ConstArgHasType` predicates in `param_env` which tell that a single const has different types. But the function `find_const_ty_from_env` panics in this situation. This assert is here for a long time, and I do not have enough knowledge to say if it is correct or not, however I have thoughts that having contradictory predicates should not lead to panic, instead an error from trait solver or whatever engine that solves those predicates should be reported. Do not want to dive too deep into researching and possibly rewriting `find_const_ty_from_env`, so fixed it on delegation level. Fixes rust-lang#158675. Part of rust-lang#118212. r? @petrochenkov
…=hanna-kruppe
Simplify `Option::into_flat_iter` signature
```diff
impl<T: IntoIterator> Option<T> {
- pub fn into_flat_iter<A>(self) -> OptionFlatten<A>
- where
- T: IntoIterator<IntoIter = A>,
+ pub fn into_flat_iter(self) -> OptionFlatten<T::IntoIter> {
}
```
This is marked as an unresolved question (rust-lang#148441, rust-lang#148487 (comment)), but I cannot come up with any reason to have this generic.
rustbot
added
A-attributes
Contributor
Author
Contributor
rust-bors
Bot
added
S-waiting-on-bors
This comment has been minimized.
This comment has been minimized.
rust-bors Bot
pushed a commit
that referenced
this pull request
Jul 8, 2026
Rollup of 12 pull requests try-job: dist-various-1 try-job: test-various try-job: x86_64-gnu-aux try-job: x86_64-gnu-llvm-21-3 try-job: x86_64-msvc-1 try-job: aarch64-apple try-job: x86_64-mingw-1 try-job: i686-msvc-2
Collaborator
|
The job Click to see the possible cause of the failure (guessed by this bot) |
rust-bors
Bot
added
S-waiting-on-author
Contributor
|
PR #158168, which is a member of this rollup, was unapproved. This rollup was thus unapproved. |
rustbot
removed
the
S-waiting-on-author
rust-bors
Bot
added
the
S-waiting-on-author
Contributor
|
💔 Test for 17611fb failed: CI. Failed jobs:
|
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
14 participants
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:
set_permissions_nofollowfor all primary platforms #158168 (Added implementation onset_permissions_nofollowfor all primary platforms)std::io::Writetocore::io#158541 (Movestd::io::Writetocore::io)x perf compare#158932 (Do not build the compiler when invokingx perf compare)ConstArgHasTypepredicates #158722 (delegation: do not always inheritConstArgHasTypepredicates)Option::into_flat_itersignature #158741 (SimplifyOption::into_flat_itersignature)r? @ghost
Create a similar rollup