Rollup of 15 pull requests#159107
Open
JonathanBrouwer wants to merge 35 commits into
Open
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`
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.
…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
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
Update LLVM Backport the fix for rust-lang#159035.
… r=JonathanBrouwer Apply MCP 1003 and move diagnostics.rs into its own module Part of 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
…error, r=JohnTitor Add `io::ErrorKind::InputOutputError` Adds an unstable `io::ErrorKind::InputOutputError` for low-level I/O failures. `EIO` currently decodes to `ErrorKind::Uncategorized`, so stable code cannot tell that an operation failed at the low-level I/O layer without inspecting `raw_os_error()` and a platform-specific `libc`/`windows-sys` constant. Implements the accepted ACP rust-lang/libs-team#824. The variant name is still open for bikeshedding before stabilization (see the ACP); this uses `InputOutputError` as accepted for now. The variant maps: - `EIO` on Unix, WASI, and teeos - `ERROR_IO_DEVICE` on Windows - `FR_DISK_ERR` on VEXos I didn't add a test, since the decode tables don't have one today (same as rust-lang#158326). Tracking issue: rust-lang#159066 r? libs
make volatile operations const This came up in gfx-rs/wgpu#8897 (comment). The tl;dr is that it can be useful to have shared codepaths between things that need to work on special memory (and hence need to use volatile) and things that work on regular Rust memory, and for the regular Rust memory case those things totally could and should be `const fn`. So, let's (unstably, for now) allow volatile reads and writes in `const`, and specify them to behave just like normal reads and writes. In const we *know* that there's nobody trying to observe those locations so there's nothing special we have to do with those accesses. Cc @rust-lang/opsem @rust-lang/wg-const-eval Tracking issue: rust-lang#159094
rustbot
added
A-LLVM
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 15 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-*
rust-bors
Bot
added
S-waiting-on-author
Contributor
|
☔ The latest upstream changes (presumably #158942) made this pull request unmergeable. Please resolve the merge conflicts by rebasing. This pull request was unapproved. |
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
16 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