Rollup of 12 pull requests#158047
Conversation
LLVM 23 recently changed SimplifyCFG to avoid integer lookup tables, and that perturbed these two tests in ways that look harmless to me.
When a `for` loop is missing its `in`, the parser suggested inserting one based only on the token after the pattern. A malformed binding such as `for i i in 0..10` was therefore "corrected" to `for i in i in 0..10`, which does not parse. Only suggest inserting `in` when the loop header does not already contain one before the body.
When passing multiple `-Zsanitizer` flags to the compiler (e.g., `-Zsanitizer=address -Zsanitizer=shadow-call-stack`), the options parser was overwriting the previous values in `target_modifiers` instead of accumulating them. This resulted in only the last sanitizer being recorded in the crate metadata's target modifiers, even though the frontend correctly enabled all of them. The only way to provide multiple sanitizers was to combine them into a comma-separated list passed to a single `-Zsanitizer=` flag, but this does not fit well into the GN build system where different targets may pass different combinations of sanitizer flags. Consequently, this caused spurious "incompatible target modifiers" ABI mismatch errors when linking against dependencies compiled with accumulated flags (e.g., `-Zsanitizer=address,shadow-call-stack`). Fix this by entry-modifying the `target_modifiers` map to accumulate the sanitizers as a comma-separated list when the option is `sanitizer`. Also add a codegen test verifying that both CFI and SafeStack attributes/metadata are present when enabled together via multiple flags. Test: ./x.py test tests/codegen-llvm/sanitizer/multiple-sanitizers.rs
In rust interger divide by zero is defined to panic, thus the inserted conditional trap should never trigger as the program should have panicked if the divisor is zero. So disable the insertion of the redundant conditional trap.
… r=petrochenkov Accumulate multiple -Zsanitizer target modifiers When passing multiple `-Zsanitizer` flags to the compiler (e.g., `-Zsanitizer=address -Zsanitizer=shadow-call-stack`), the options parser was overwriting the previous values in `target_modifiers` instead of accumulating them. This resulted in only the last sanitizer being recorded in the crate metadata's target modifiers, even though the frontend correctly enabled all of them. The only way to provide multiple sanitizers is to combine them into a comma-separated list passed to a single `-Zsanitizer=` flag, but this doesn't fit very well into the GN build system where different targets may pass different combinations of sanitizer flags. Consequently, this caused spurious "incompatible target modifiers" ABI mismatch errors when linking against dependencies compiled with accumulated flags. Fix this by entry-modifying the `target_modifiers` map to accumulate the sanitizers as a comma-separated list when the option is `sanitizer`.
…mfix, r=joboet Stabilize `strip_circumfix` Tracking issue: rust-lang#147946
…i865 Query the trait solver in slow path for `missing_debug_implementations` Fixes rust-lang#157757 Fixes rust-lang#157758
tests: adapt two tests for LLVM 23 changes LLVM 23 recently changed SimplifyCFG to avoid integer lookup tables, and that perturbed these two tests in ways that look harmless to me.
…=folkertdev mips: set llvm_args -mno-check-zero-division for all mips targets In rust interger divide by zero is defined to panic, thus the inserted conditional trap should never trigger as the program should have panicked if the divisor is zero. So disable the insertion of the redundant conditional trap.
…-field-mgca-adt-const, r=camelid Reject extra fields in MGCA struct const arguments closes: rust-lang#154538 r? @BoxyUwU
…estion-103561, r=folkertdev Don't suggest adding `in` to a `for` loop that already has one Closes rust-lang#103561. When a `for` loop is missing its `in`, the parser suggested inserting one based only on the token following the pattern. For a malformed binding such as `for i i in 0..10` it therefore suggested `for i in i in 0..10`, which is itself invalid. The suggestion is now only emitted when the loop header does not already contain an `in` before the body. The `for x EXPR` / `for x of EXPR` / `for x = EXPR` suggestions are unchanged.
…ble-shim, r=folkertdev Preserve track_caller for by-value dyn vtable shims Fixes rust-lang#157964
…, r=petrochenkov delegation: add simple test for incremental compilation Progress on incremental lowering (rust-lang#142830) fixed rust-lang#155729 by removing delayed lowering at all. Fixes rust-lang#155729. Part of rust-lang#118212. r? @petrochenkov
…ate, r=mejrs Move `UnusedDuplicate` diag struct to `rustc_attr_parsing` This was moved there in rust-lang#154432, I am not entirely sure why there? This was probably an oversight, at least I missed this during review cc @GuillaumeGomez r? @mejrs
Rename `project-stable-mir` to `project-rustc-public` Per rust-lang/team#2522
Add more tests for parallel frontend issues Issues: - rust-lang#153366 - rust-lang#154056 - rust-lang#154560 2 issues still reproduce (and therefore marked with `//@ ignore-parallel-frontend query`), 1 issue doesn't reproduce. Closes rust-lang#153366.
This comment has been minimized.
This comment has been minimized.
Rollup of 12 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.
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 c1b22f4 (parent) -> f7da3c0 (this PR) Test differencesShow 619 test diffsStage 1
Stage 2
(and 11 additional test diffs) Additionally, 508 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 f7da3c0d4b3a4cc291f8c800cc61549d27d14c49 --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 |
|
📌 Perf builds for each rolled up PR:
previous master: c1b22f44c3 In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
|
Finished benchmarking commit (f7da3c0): 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 (secondary -2.8%)A less reliable metric. May be of interest, but not used to determine the overall result above.
CyclesResults (secondary 3.2%)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: 523.599s -> 522.85s (-0.14%) |
Successful merges:
strip_circumfix#158012 (Stabilizestrip_circumfix)missing_debug_implementations#157810 (Query the trait solver in slow path formissing_debug_implementations)into aforloop that already has one #157917 (Don't suggest addinginto aforloop that already has one)UnusedDuplicatediag struct torustc_attr_parsing#158023 (MoveUnusedDuplicatediag struct torustc_attr_parsing)project-stable-mirtoproject-rustc-public#158029 (Renameproject-stable-mirtoproject-rustc-public)r? @ghost
Create a similar rollup