Rollup of 8 pull requests - #163300
Merged
Merged
Rollup of 8 pull requests#163300
Conversation
… tidy We ship the entire library workspace in the rust-src component, so even if the standard library doesn't depend on a crate, having it in the library workspace still increases the amount of storage a rust install takes. And for cg_clif I personally want to keep deps to a minimum even those not for the backend itself.
Some pauth tests have ended up failing since they were not run in CI. Make them run and make them pass.
Some were wholly unused, others were unused other than as dev-deps but specified as regular dependencies. This cleans things up a little bit. I used an LLM to smoke out the candidates for this cleanup, but the rest was done by hand.
…r=Enselic tests: Run more pauth tests in CI and make them pass Some pauth tests have ended up failing since they were not run in CI. Make them run and make them pass. This is a follow up to: rust-lang#161183
add a leak check test it's jank r? types
cleanup: clean up more dependencies that are unused Some were wholly unused, others were unused other than as dev-deps but specified as regular dependencies. This cleans things up a little bit. I used an LLM to smoke out the candidates for this cleanup, but the rest was done by hand.
…out, r=Kivooeo Avoid computing layout of enums with non-int discriminants Currently, enums with explicit non-int discriminants, such as `1..=10`, correctly error with E0308 and E0732 during typeck. However, `layout_of` never sees this error, since `AdtDef::discriminants()` falls back to a default value when `eval_explicit_discr` returns an `Err`, causing the layout of the enum to be broken. If this enum then appears in a promoted, we expect CTFE to fail; however, since `layout_of` technically "succeeded," just with a broken layout, our enum isn't in `allowed_in_infallible`, so CTFE expects it to succeed. CTFE failing then causes us to ICE with `"interpret const eval failure of...which is not in required_consts"`. This PR modifies `layout_of_uncached` in `compiler/rustc_ty_utils/src/layout.rs` to typeck all explicit enum discriminants before computing layout, and early-returns with a `LayoutError::ReferncesError` if eval fails. CTFE then sees this `LayoutError` as `allowed_in_infallible`, avoiding the ICE. fixes rust-lang#138660
Do not increase recursion depth for coroutine witness and rigid opaques when proving auto traits With deeply nested async calls, we can easily overflow evaluating auto trait goals as shown in rust-lang#159228. Users have no choice but increase the per-crate `recursion_limit` which is bad for compilation time/RSS. And downstream users may encounter the same warnings when calling library async functions. We mitigate that by no longer increasing recursion depth for coroutine witness and rigid opaques when proving auto traits. See the comments for why it's okay to do so. This fix actually makes the required depth a third of what it was before for async calls. I've checked locally that `bors` and `triagebot` no longer have FCWs. r? lcnr
fix and test `va_arg` on `f128` on `x86` tracking issue: rust-lang#116909 Or well, maybe not fix but clarify. There are no actual behavioral changes, but I do think the new code is more correct. The clang logic for `va_arg` is kind of (weirdly) complicated. `EmitVAArg` looks simple, but the complexity is hiding in the "messing with TypeInfo" bit: https://github.com/llvm/llvm-project/blob/0e2786dcb5b28f754a1144c27e708d1c42676af9/clang/lib/CodeGen/Targets/X86.cpp#L1080-L1101 ```c++ RValue X86_32ABIInfo::EmitVAArg(CodeGenFunction &CGF, Address VAListAddr, QualType Ty, AggValueSlot Slot) const { auto TypeInfo = getContext().getTypeInfoInChars(Ty); CCState State(*const_cast<CGFunctionInfo *>(CGF.CurFnInfo)); ABIArgInfo AI = classifyArgumentType(Ty, State, /*ArgIndex*/ 0); // Empty records are ignored for parameter passing purposes. if (AI.isIgnore()) return Slot.asRValue(); // x86-32 changes the alignment of certain arguments on the stack. // // Just messing with TypeInfo like this works because we never pass // anything indirectly. TypeInfo.Align = CharUnits::fromQuantity( getTypeStackAlignInBytes(Ty, TypeInfo.Align.getQuantity())); return emitVoidPtrVAArg(CGF, VAListAddr, Ty, /*Indirect*/ false, TypeInfo, CharUnits::fromQuantity(4), /*AllowHigherAlign*/ true, Slot); } ``` Relevant for us is that it makes an exception for `f128`, for which a higher align (16, instead of the slot size of 4) is used. https://github.com/llvm/llvm-project/blob/0e2786dcb5b28f754a1144c27e708d1c42676af9/clang/lib/CodeGen/Targets/X86.cpp#L575-L583 ```c++ unsigned X86_32ABIInfo::getTypeStackAlignInBytes(QualType Ty, unsigned Align) const { // Otherwise, if the alignment is less than or equal to the minimum ABI // alignment, just use the default; the backend will handle this. if (Align <= MinABIStackAlignInBytes) return 0; // Use default alignment. if (Ty->isFloat128Type()) return 16; ``` Our code does not have this `TypeInfo` idea, and it's not correct in general to just use `AllowHigherAlign::Yes`. But using it only for `f128` works. We don't need to consider more complicated cases like structs containing `f128` fields. The code here used `is_like_windows` before. I'm not exactly sure why, the behavior is the same for all accepted types, except now `f128`. But windows does not have that type, so its (c-variadic) ABI is just an LLVM fabrication. The x86 code does not seem to make a distinction based on the ABI, so having the same behavior across targets seems best to me. `va_arg` to fetch an `i128` argument is currently broken in clang. `i128` on the target is apparently a clang extension anyway, so kind of low priority. `f128` I only fixed somewhat recently in llvm/llvm-project#218017. r? beetrees or @tgross35 (this may cause a small conflict with rust-lang#163021)
Add regression test for hang on mutually recursive trait impls Fixes rust-lang#143018, it no longer hangs, it hung on nightlies through 2026-08-08 and terminates with an error from 2026-08-11
…clubby789 Check the entire library and cg_clif workspaces for permitted deps in tidy We ship the entire library workspace in the rust-src component, so even if the standard library doesn't depend on a crate, having it in the library workspace still increases the amount of storage a rust install takes. And for cg_clif I personally want to keep deps to a minimum even those not for the backend itself.
Member
Author
|
@bors r+ p=5 force |
Contributor
This comment has been minimized.
This comment has been minimized.
Contributor
This was referenced Sep 25, 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 7618355 (parent) -> 4e701dc (this PR) Test differencesShow 109 test diffsStage 1
Stage 2
(and 7 additional test diffs) Additionally, 2 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 4e701dc6ba63a40c908a173df269a55e1fd6297e --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
|
Finished benchmarking commit (4e701dc): comparison URL. Overall result: ❌ regressions - no action needed@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 -2.1%)A less reliable metric. May be of interest, but not used to determine the overall result above.
CyclesResults (primary 0.5%, secondary 1.4%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Binary sizeThis perf run didn't have relevant results for this metric. Bootstrap: 492.862s -> 488.984s (-0.79%) |
Contributor
|
📌 Perf builds for each rolled up PR:
parent commit: 7618355fd7 In the case of a perf regression, run the following command with the SHAs of each PR you suspect might be the cause: |
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:
va_argonf128onx86#163037 (fix and testva_argonf128onx86)r? @ghost
Create a similar rollup