Rollup of 7 pull requests#155292
Conversation
When a coroutine has too many parameters, `check_match` fails and `construct_error` builds a MIR body with only the coroutine's computed args (env + resume type). The user-provided signature, however, still reflects all the parameters the user wrote. `check_signature_annotation` then tries to `zip_eq` these two mismatched iterators, causing a panic. Checking `tainted_by_errors` and bailing early avoids this, since `construct_error` bodies cannot meaningfully be compared against user annotations.
The local trim_ascii_start function in the markdown parser duplicates <[u8]>::trim_ascii_start() from the standard library (stable since 1.80). Remove the custom function and call the stdlib method directly. No behaviour change. Fixes rustfoundation/interop-initiative#53
The span location of the last segment in the desugared path is inherited from the star symbol's span
…on body Instead of the last segment of the delegation path. `self` is something that introduced by the whole delegation item, not some specific part of it, and the last segment may need to have a different context for path resolution purposes.
This reverts commit 472b966.
delegation: Track more precise spans for glob delegations The last commit also fixes a macro hygiene issue with `self` in delegations found in rust-lang#154002.
…-start-with-stdlib, r=mati865 Replace custom trim_ascii_start with the standard library method The markdown parser in `rustc_errors` has a local `trim_ascii_start` function that strips leading ASCII whitespace from a byte slice. The standard library has had `<[u8]>::trim_ascii_start()` since Rust 1.80, which does the same thing. This PR removes the custom function and calls the stdlib method directly in `parse_unordered_li` and `parse_ordered_li`. No behaviour change. I also added a test covering the list item leading-whitespace trimming behaviour, including a tab case. Fixes rustfoundation/interop-initiative#53
…sayantn add the `fma4` x86 target feature tracking issue: rust-lang#155233 Implications are based on LLVM https://github.com/llvm/llvm-project/blob/df6c82053c5e1f9814d130d423f34871bc6423c5/llvm/lib/Target/X86/X86.td#L201-L206 This feature adds a slightly better instruction encoding for fma. We might want to expose the intrinsics in `stdarch` with that target feature, but just adding the target feature in user code should already take advantage of this improved encoding. This target feature is used in `libm`. r? sayantn
coroutines: Skip the closure signature annotation check for tainted bodies
When a coroutine has too many parameters, `check_match` fails and `construct_error` builds a MIR body with only the coroutine's computed arguments (env + resume type). The user-provided signature, however, still reflects all the parameters the user wrote. `check_signature_annotation` then tries to `zip_eq` these two mismatched iterators, causing a panic. Checking `tainted_by_errors` and bailing early avoids this, since `construct_error` bodies cannot meaningfully be compared against user annotations.
Example currently ICEing:
```rust
fn main() {
|(1, 42), ()| yield;
}
```
Closes rust-lang#139570.
limit duplicate-profiler-builtins test to targets that can do dynamic linking this is the error I got for an example of such a target ``` === STDERR === error: extern location for dylib_a does not exist: libdylib_a.so --> main.rs:2:5 | 2 | dylib_a::something(); | ^^^^^^^ error: extern location for dylib_b does not exist: libdylib_b.so --> main.rs:3:5 | 3 | dylib_b::something_else(); | ^^^^^^^
…ly-let-else, r=JonathanBrouwer `#[rustc_must_match_exhaustively]` detect let else Extension of rust-lang#155047, I forgor to lint on let-else :3
…tdev Revert "allow `windows-gnu` targets to embed gdb visualizer scripts" Fixes rust-lang#155277 This reverts commit 472b966. This was merged as rust-lang#154840, but causes linker errors in the wild. cc @Walnut356 @mati865 r? @ghost
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-2
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
|
Seems a little stuck but given that the stuck job is |
|
📌 Perf builds for each rolled up PR:
previous master: 12f35ad39e In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
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 12f35ad (parent) -> a5c825c (this PR) Test differencesShow 33 test diffsStage 0
Stage 1
Stage 2
Additionally, 21 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 a5c825cd824ee0ef9463021078a2f464b4cc1a0d --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 |
Successful merges:
fma4x86 target feature #155235 (add thefma4x86 target feature)#[rustc_must_match_exhaustively]detect let else #155276 (#[rustc_must_match_exhaustively]detect let else)windows-gnutargets to embed gdb visualizer scripts" #155281 (Revert "allowwindows-gnutargets to embed gdb visualizer scripts")r? @ghost
Create a similar rollup