Rollup of 10 pull requests#159077
Closed
JonathanBrouwer wants to merge 22 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.
Since PR 154149, when one item is glob-imported into a module twice with different visibilities, the first-arrived declaration stays in the resolution slot and the most visible declaration of the ambiguous glob set is only recorded in `ambiguity_vis_max`. `DeclData::vis()` returns the max, so name resolution, metadata reexports and `cross_crate_inlinable` export the item at the maximum visibility, but `set_bindings_effective_visibilities` walked only the slot-resident declaration's reexport chain. When the restricted route arrives first, the definition's effective visibility caps at the restricted visibility while the item is still exported: spurious dead_code, the item missing from reachable_set, should_encode_mir returning false, and downstream crates failing with "missing optimized MIR" (a 1.96.1 -> 1.97.0 stable-to-stable regression). Generalize the one-level `ambiguity_vis_max` update that PR 154149 added in `update_import` (to keep the most visible import from being reported as unused) into a walk of that declaration's whole reexport chain: extract the chain walk into `update_decl_chain` and recurse into `ambiguity_vis_max` at every hop, so the most visible declaration drives the effective visibility of everything on its route, including the final definition. Updates are monotone, so the dual walk is order-independent. The `ambiguous_import_visibilities` lint and the PR 156284 diagnostic suppression are untouched.
… `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.
…biguity, r=petrochenkov resolve: fix effective visibilities for items in ambiguous glob sets Fixes rust-lang#159038 (1.96.1 → 1.97.0 regression; details there). When an item is glob-imported twice at different visibilities, effective visibility was computed from whichever declaration arrived first, not the most visible one. An exported item could then get no MIR encoded, and downstream crates fail with ``missing optimized MIR``. Fix: also walk the most visible declaration's re-export chain (`update_decl_chain`, recursing into `ambiguity_vis_max`). Lint behavior unchanged. Two regression tests added; `tests/ui/{imports,privacy,resolve}` pass with every rust-lang#154149 / rust-lang#156284 test unmodified. @rustbot label +A-resolve +A-visibility +T-compiler +regression-from-stable-to-stable
… r=JonathanBrouwer Apply MCP 1003 and move diagnostics.rs into its own module Fixes rust-lang#158699. r? @JonathanBrouwer
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
Reorganize `tests/ui/issues` [21/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
…yuVanilla assert only opaques with sub unified hidden infer are non-rigid Fixes rust-lang#158784 r? lcnr
…anilla Remove unused WEAK_ONLY_LANG_ITEMS static
rustbot
added
S-waiting-on-review
Contributor
Author
Contributor
rust-bors
Bot
added
S-waiting-on-bors
rust-bors Bot
pushed a commit
that referenced
this pull request
Jul 10, 2026
Rollup of 10 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-*
This comment has been minimized.
This comment has been minimized.
rust-bors
Bot
added
S-waiting-on-author
Contributor
|
This pull request was unapproved due to being closed. |
Contributor
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
11 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)tests/ui/issues[20/N] #158930 (Reorganizetests/ui/issues[20/N])tests/ui/issues[21/N] #158979 (Reorganizetests/ui/issues[21/N])r? @ghost
Create a similar rollup