Rollup of 7 pull requests#159068
Closed
JonathanBrouwer wants to merge 16 commits into
Closed
Conversation
Signed-off-by: Amirhossein Akhlaghpour <m9.akhlaghpoor@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.
… `error_helper.rs` into the `diagnostics` folder in `rustc_resolve`
…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.
… r=JonathanBrouwer Apply MCP 1003 and move diagnostics.rs into its own module Fixes rust-lang#158699. r? @JonathanBrouwer
…nathanBrouwer Add `#[rustc_test_entrypoint_marker]` r? @JonathanBrouwer cc: @Nadrieril @N1ark @aDotInTheVoid Some context: a bunch of tooling around rustc likes to find entry points. This is easy for `main`, it's a lang item. But tests aren't as easy. There is already a similar marker for the data structure associated with tests, but if you want to do for example dynamic analysis, you want just the defid of the function you can call to start the tests. This is that marker. There's a test using a rustc driver that the attr indeed shows up and marks the test functions. @Nadrieril and @N1ark asked for this kind of behavior. I talked to @aDotInTheVoid about whether we should do things like this where we cannot really guarantee the stability or even use it inside rustc. The thing is, we don't provide staboility guarantees, it's just a useful little thing to have for as long as its there and it doesn't bother anyone either. It's up to tool authors to deal with breakage we may introduce.
…s-ok-unwrap, r=nnethercote Add codegen test for Result is_ok unwrap Closes rust-lang#85771
…yuVanilla assert only opaques with sub unified hidden infer are non-rigid Fixes rust-lang#158784 r? lcnr
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 10, 2026
Rollup of 7 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-*
Contributor
|
⌛ Testing commit 36c39bb with merge 0c33526... Workflow: https://github.com/rust-lang/rust/actions/runs/29088515701 |
rust-bors Bot
pushed a commit
that referenced
this pull request
Jul 10, 2026
…uwer Rollup of 7 pull requests Successful merges: - #157690 (codegen_ssa: pack small const aggregates into immediate stores) - #159005 (Use `as_lang_item` instead of repeatedly matching) - #156735 (Move NativeLib::filename to the rmeta-link archive member) - #158732 (Apply MCP 1003 and move diagnostics.rs into its own module) - #158854 (Add `#[rustc_test_entrypoint_marker]`) - #158965 (Add codegen test for Result is_ok unwrap) - #159050 (assert only opaques with sub unified hidden infer are non-rigid)
Contributor
Author
|
@bors yield |
Contributor
|
Auto build was cancelled. Cancelled workflows: The next pull request likely to be tested is #159047. |
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 #158854, which is a member of this rollup, was unapproved. |
rustbot
removed
the
S-waiting-on-author
rust-bors
Bot
added
the
S-waiting-on-author
Contributor
|
💔 Test for 67a2731 failed: CI. Failed job:
|
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
10 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)#[rustc_test_entrypoint_marker]#158854 (Add#[rustc_test_entrypoint_marker])r? @ghost
Create a similar rollup