Rollup of 15 pull requests#159113
Merged
Merged
Conversation
Signed-off-by: Amirhossein Akhlaghpour <m9.akhlaghpoor@gmail.com>
Co-authored-by: lolbinarycat <dogedoge61+github@gmail.com>
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.
used as `GlobalAlloc`s
`EIO` decoded to `ErrorKind::Uncategorized`, so a low-level I/O failure could only be detected through `raw_os_error()`. Map it, and the equivalent codes on Windows (`ERROR_IO_DEVICE`) and VEXos (`FR_DISK_ERR`), to a new unstable `InputOutputError` variant.
Update LLVM Backport the fix for rust-lang#159035.
…alfJung codegen_ssa: pack small const aggregates into immediate stores Close rust-lang#157373 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.
Use `as_lang_item` instead of repeatedly matching drive-by fix I noticed while reviewing https://github.com/rust-lang/rust/pull/157489/changes#r3550851573
…ochenkov Move NativeLib::filename to the rmeta-link archive member Second PR in rust-lang#138243 Moves `NativeLib::filename` out of `rmeta` into `lib.rmeta-link` archive member that was introduced in the first PR. Filename is a link time only data so requiring a full metadata decode should be avoided. It is stored as `(name, filename)` pairs keyed by name, the new `MetadataLoader::get_rlib_native_lib_filenames` patches it back on decode. Also bumped `METADATA_VERSION` from version 10 to 11. Added also new round trip test and existing bundled-libs tests still pass.
allow `Allocator`s to be used as `#[global_allocator]`s The (hopefully) immanent stabilisation of the `Allocator` trait raises the question of what is to be done about the older, already-stable `GlobalAlloc` trait. In my opinion, having two nearly-identical traits for the same purpose is needlessly confusing. Going forward, `Allocator` as the more modern interface should be _the_ allocator trait. With `Allocator` being currently unstable, there is the possibility of implementing `GlobalAlloc` for all `Allocator`s, thereby allowing them to be used as `#[global_allocator]` and allowing crates to seamlessly (and semver-compatibly) switch to `Allocator`. However, unconditionally implementing `GlobalAlloc` presents a footgun to users, as e.g. using `Global` as `#[global_allocator]` will lead to infinite recursion. @nia-e initially tried to resolve this in e1b7097 (rust-lang#156882) by using weird trait trickery to implement `GlobalAlloc` for every allocator except `Global`. But this does not go far enough, e.g. a bump allocator that itself allocates from `Global` is similarly unsuitable as global allocator. Thus, with this PR, I'd like to propose adding a new marker trait for allocators that can be used as `#[global_allocator]`: ```rust // in core::alloc trait GlobalAllocator: Allocator {} ``` `GlobalAlloc` can then be implemented for all `GlobalAllocator`s: ```rust impl<A> GlobalAlloc for A where A: GlobalAllocator { /* ... */ } ``` This provides a backwards-compatible way for allocator libraries to switch to the new interface and allows deprecating `GlobalAlloc` (not done here). Over time, I expect that `GlobalAlloc` will become more and more of an implementation detail of the `#[global_allocator]` macro (for instance, one might add perma-unstable, hidden methods for things like `grow_zeroed` that are customised only by the blanket implementation). With regards to naming, I chose `GlobalAllocator` to mirror `Allocator`. `GlobalAlloc` should probably be deprecated quickly after stabilising `GlobalAllocator` to avoid confusion. For the same reason, I think it'd be better to add `GlobalAllocator` before stabilising `Allocator` – but that is not a necessity. r? @nia-e @rustbot label +I-libs-api-nominated
jq directives for jsondocck Closes rust-lang#142479. Adds `jq` directives for `jsondocck`. I decided to add jq instead of replacing jsonpath entirely so that migration could happen incrementally. In theory, it should be possible to replace every jsonpath test case with the new `jq` directives. Moving forward, this might put more burden on reviewers as test case writers would have the option to use jq or jsonpath or even both. ~~Note that you cannot use `jq_set` with jsonpath directives or `set` with jq directives~~. Diff should be reviewed without whitespace. r? @aDotInTheVoid
merge DefKind::InlineConst into AnonConst This is a closely related followup to rust-lang#158375 (a condition of merging that PR was doing this as a followup) This merge conflicts with rust-lang#158617 ; prefer merging that one first please~ This PR is within the general goal of const generics / `generic_const_args` and perhaps specifically rust-lang/project-const-generics#108 but is mostly a code cleanup rather than implementing any particular feature --- Anon consts (the `1 + 2` in `let x: [u8; 1 + 2];`) are closely related to inline consts (the `const {}` in `let x = const { 1 + 2 };`). They are especially related now that both can be used in the type system (by the above PR) and should be treated identically in that scenario. In general, they should be treated the same, as evidenced by the number of matches touched in this PR that just match on both. This PR merges the two DefKinds into one, mostly arbitrarily and bikesheddily choosing to use the name `AnonConst` for the merged concept (e.g. both `DefKind::InlineConst` and `DefKind::AnonConst` used `ast::AnonConst`, so `ast::AnonConst` should probably be named whatever the merged `DefKind` concept is named). When you absolute must distinguish between the two, `tcx.anon_const_kind` allows you to do so - however, anon consts/inline consts in the type system intentionally appear identically under `anon_const_kind`. Indeed, the places where we distinguish between the two raised my eyebrows a few times when doing this PR, and being a little more explicit and loud about it is helpful for code clarity, IMO. r? @BoxyUwU
Stabilize String::from_utf8_lossy_owned Passed FCP in rust-lang#129436. Closes rust-lang#129436. r? libs
Reorganize `tests/ui/issues` [20/N] Part of [GSoC'26 project](https://rust-lang.zulipchat.com/#narrow/channel/421156-gsoc/topic/Project.3A.20Reorganizing.20tests.2Fui.2Fissues) r? Kivooeo @Teapot4195
…s-ok-unwrap, r=nnethercote Add codegen test for Result is_ok unwrap Closes rust-lang#85771
rust-bors
Bot
added
S-waiting-on-review
Contributor
|
💔 Test for 5543890 failed: CI. Failed job:
|
Collaborator
|
The job Click to see the possible cause of the failure (guessed by this bot) |
Member
Author
|
@bors retry |
rust-bors
Bot
added
S-waiting-on-bors
Merged
This comment has been minimized.
This comment has been minimized.
rust-bors
Bot
added
merged-by-bors
Contributor
This was referenced Jul 11, 2026
Contributor
What is this?This is an experimental post-merge analysis report that shows differences in test outcomes between the merged PR and its parent PR.Comparing 48e8ec6 (parent) -> ad49852 (this PR) Test differencesShow 646 test diffsStage 1
Stage 2
(and 58 additional test diffs) Additionally, 488 doctest diffs were found. These are ignored, as they are noisy. Job group index
Test dashboardRun cargo run --manifest-path src/ci/citool/Cargo.toml -- \
test-dashboard ad49852b6f3dd9c1c73fe909d8843bb7e464b387 --output-dir test-dashboardAnd then open Job duration changes
How to interpret the job duration changes?Job durations can vary a lot, based on the actual runner instance |
Collaborator
|
📌 Perf builds for each rolled up PR:
previous master: 48e8ec6f05 In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
Collaborator
|
Finished benchmarking commit (ad49852): comparison URL. Overall result: ❌✅ regressions and improvements - please read:Our benchmarks found a performance regression caused by this PR. Next Steps:
@rustbot label: +perf-regression Instruction countOur most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.
Max RSS (memory usage)Results (primary -0.1%, secondary 3.3%)A less reliable metric. May be of interest, but not used to determine the overall result above.
CyclesResults (primary 2.4%, secondary 0.8%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Binary sizeResults (secondary -0.0%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Bootstrap: 490.729s -> 488.317s (-0.49%) |
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
18 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:
as_lang_iteminstead of repeatedly matching #159005 (Useas_lang_iteminstead of repeatedly matching)Allocators to be used as#[global_allocator]s #157153 (allowAllocators to be used as#[global_allocator]s)tests/ui/issues[20/N] #158930 (Reorganizetests/ui/issues[20/N])tests/ui/issues[21/N] #158979 (Reorganizetests/ui/issues[21/N])io::ErrorKind::InputOutputError#159070 (Addio::ErrorKind::InputOutputError)r? @ghost
Create a similar rollup