Rollup of 13 pull requests #149629
Closed
Rollup of 13 pull requests #149629
Conversation
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
For half-open ranges, specifies that the upper bound cannot be the minimum. Also specify that this only applies to range patterns and not also expressions.
This reduces check times for miri from 2m15s to 20s. And reduces check times for miri with --compile-time-deps from 1m50s to 7s. This makes rust-analyzer start a lot faster after switching branches.
…ngjubilee Rework `c_variadic` tracking issue: rust-lang#44930 related PR: rust-lang#144529 On some platforms, the C `va_list` type is actually a single-element array of a struct (on other platforms it is just a pointer). In C, arrays passed as function arguments expirience array-to-pointer decay, which means that C will pass a pointer to the array in the caller instead of the array itself, and modifications to the array in the callee will be visible to the caller (this does not match Rust by-value semantics). However, for `va_list`, the C standard explicitly states that it is undefined behaviour to use a `va_list` after it has been passed by value to a function (in Rust parlance, the `va_list` is moved, not copied). This matches Rust's pass-by-value semantics, meaning that when the C `va_list` type is a single-element array of a struct, the ABI will match C as long as the Rust type is always be passed indirectly. In the old implementation, this ABI was achieved by having two separate types: `VaList` was the type that needed to be used when passing a `VaList` as a function parameter, whereas `VaListImpl` was the actual `va_list` type that was correct everywhere else. This however is quite confusing, as there are lots of footguns: it is easy to cause bugs by mixing them up (e.g. the C function `void foo(va_list va)` was equivalent to the Rust `fn foo(va: VaList)` whereas the C function `void bar(va_list* va)` was equivalent to the Rust `fn foo(va: *mut VaListImpl)`, not `fn foo(va: *mut VaList)` as might be expected); also converting from `VaListImpl` to `VaList` with `as_va_list()` had platform specific behaviour: on single-element array of a struct platforms it would return a `VaList` referencing the original `VaListImpl`, whereas on other platforms it would return a cioy, In this PR, there is now just a single `VaList` type (renamed from `VaListImpl`) which represents the C `va_list` type and will just work in all positions. Instead of having a separate type just to make the ABI work, rust-lang#144529 adds a `#[rustc_pass_indirectly_in_non_rustic_abis]` attribute, which when applied to a struct will force the struct to be passed indirectly by non-Rustic calling conventions. This PR then implements the `VaList` rework, making use of the new attribute on all platforms where the C `va_list` type is a single-element array of a struct. Cleanup of the `VaList` API and implementation is also included in this PR: since it was decided it was OK to experiment with Rust requiring that not calling `va_end` is not undefined behaviour (rust-lang#141524 (comment)), I've removed the `with_copy` method as it was redundant to the `Clone` impl (the `Drop` impl of `VaList` is a no-op as `va_end` is a no-op on all known platforms). Previous discussion: rust-lang#141524 and [t-compiler > c_variadic API and ABI](https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/c_variadic.20API.20and.20ABI) Tracking issue: rust-lang#44930 r? ```@joshtriplett```
…flelapkin Fix ICE when applying test macro to crate root This PR does a couple of things. First of all, I found [an ICE](https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=a733a7f3d223e1a9712e44b571f3e5cf) that happens when applying `#![core::prelude::v1::test]` to the crate root. This is caused by the test macro not expanding to an item when `--test` isn't applied. For the crate root, that means it deletes the crate.... The fix now first does target checking, and only if the target is valid discards the item when `--test` isn't applied. The discarding is, I think, important for perf. The problem with this PR is that it means that `#[test]` applied to structs previously would give no errors unless `--test` is applied! That sounds like a bug to me, but maybe we should crater run it just in case, since technically that's a breaking change. Errors in such items wouldn't be reported previously. Also fixed a smol diagnostics bug with `#[bench]`'s error messages refering to `#[test]` accidentally. r? noratrieb (since I already explained you a bunch, feel free to re-assign) Fixes rust-lang#114920
…nments-macro-gen-147648, r=JonathanBrouwer Fix unused_assignments false positives from macros Fixes rust-lang#147648
Use `TypingMode::PostAnalysis` in `try_evaluate_const` As mentioned in rust-lang#148698 (comment), we should use ``TypingMode::PostAnalysis`` for that path. ```@BoxyUwU``` prefer the match in ``try_evaluate_const`` to be exhaustive, so I also included that in this PR :3
…lacrum std: don't call `current_os_id` from signal handler `current_os_id` is not always async-signal-safe depending on the platform, hence it may not be called from the SIGSEGV handler. Instead, store the thread ID along with the thread name during setup. With rust-lang#144465 merged, this information is available even before the thread main function.
…, r=lqd,oli-obk CTFE: avoid emitting a hard error on generic normalization failures Fixes rust-lang#149081. The fix is quite unsatisfying and should not be necessary, cc rust-lang#149283. That change is significantly more involved. This temporary fix introduces some unnecessary complexity and may hide other type system bugs. cc ```@rust-lang/types``` I think we should try to fix issue rust-lang#149283 in the near future and then remove this hack again. I originally intended a more targeted fix. I wanted to skip evaluating constants in MIR opts if their body was polymorphic and the current generic arguments still reference generic parameters. Notes from looking into this: - we only fetch the MIR in the `eval_to_allocation_raw` query - figuring out which MIR to use is hard - dealing with trivial consts is annoying - need to resolve instances for associated consts - implementing this by hand is hard - inlining handles this issue by bailing on literally all normalization failures, even the ones that imply an unsoundness - `try_normalize_after_erasing_regions` generally does two things - deal with ambiguity after inlining - deal with error tainting issues (please don't, we should stop doing that) - CTFE could be changed to always silently ignore normalization failures if we're in a generic body - hides actual bugs <- went with this option r? types
…, r=jieyouxu reword error for invalid range patterns For half-open ranges, specifies that the upper bound cannot be the minimum. Also specify that this only applies to range patterns and not also expressions. Fixes rust-lang#149165
…ark-Simulacrum
Additional test for uN::{gather,scatter}_bits
Feature gate: #![feature(uint_gather_scatter_bits)]
Tracking issue: rust-lang#149069
Accepted ACP: rust-lang/libs-team#695 (comment)
Adds an additional runtime test for `uN::gather_bits` and `uN::scatter_bits` in coretests. They are each other's inverses in a sense, so a shared test can test both with relative ease.
I plan to follow up with optimized implementations for these functions.
…-ttbr0_el2, r=WaffleLapkin Regression test for system register `ttbr0_el2` Regression test for recognising the `ttbr0_el2` register. closes rust-lang#97724
…=RalfJung Disable native-lib for x check miri This reduces check times for miri from 2m15s to 20s. And reduces check times for miri with --compile-time-deps from 1m50s to 7s. This makes rust-analyzer start a lot faster after switching branches. r? ``@RalfJung``
…=Mark-Simulacrum build-manifest: generate MSI and MINGW arrays from rustc An alternative to rust-lang#149503 The arrays after generating: ``` ❯ bat -n build/x86_64-unknown-linux-gnu/stage2-tools/x86_64-unknown-linux-gnu/release/build/build-manifest-e0236666c7c4187b/out/targets.rs | rg MSI -A14 136 static MSI_INSTALLERS: &[&str] = &[ 137 "aarch64-pc-windows-gnullvm", 138 "aarch64-pc-windows-msvc", 139 "i686-pc-windows-gnu", 140 "i686-pc-windows-msvc", 141 "x86_64-pc-windows-gnu", 142 "x86_64-pc-windows-gnullvm", 143 "x86_64-pc-windows-msvc", 144 ]; 145 static MINGW: &[&str] = &[ 146 "aarch64-pc-windows-gnullvm", 147 "i686-pc-windows-gnu", 148 "x86_64-pc-windows-gnu", 149 "x86_64-pc-windows-gnullvm", 150 ]; ``` r? ``@Mark-Simulacrum``
…d, r=workingjubilee c-variadic: bpf and spirv do not support c-variadic definitions tracking issue: rust-lang#44930 Emit a nice error message on bpf and spirv targets when a c-variadic function is defined. Spirv also does not support c-variadic calls, bpf appears to allow them. r? ``@workingjubilee``
Fix mailmap issue My name and username got separated in thanks.rust-lang.org, probably due to me changing my email in Github about a month ago.
rustbot
added
A-compiletest
Member
Author
|
@bors r+ rollup=never p=5 |
Collaborator
bors
added
S-waiting-on-bors
Member
Author
|
@bors try jobs=x86_64-msvc-1,i686-msvc-1,x86_64-mingw-1,test-various,armhf-gnu,aarch64-apple,x86_64-gnu-llvm-20-3 |
This comment has been minimized.
This comment has been minimized.
rust-bors bot
added a commit
that referenced
this pull request
Dec 4, 2025
Rollup of 13 pull requests try-job: x86_64-msvc-1 try-job: i686-msvc-1 try-job: x86_64-mingw-1 try-job: test-various try-job: armhf-gnu try-job: aarch64-apple try-job: x86_64-gnu-llvm-20-3
Collaborator
|
The job Click to see the possible cause of the failure (guessed by this bot) |
|
💔 Test for f1326ce failed: CI. Failed jobs:
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
17 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:
c_variadic: makeVaListabi-compatible with C #141980 (Reworkc_variadic)TypingMode::PostAnalysisintry_evaluate_const#149183 (UseTypingMode::PostAnalysisintry_evaluate_const)current_os_idfrom signal handler #149456 (std: don't callcurrent_os_idfrom signal handler)ttbr0_el2#149549 (Regression test for system registerttbr0_el2)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup