Rollup of 17 pull requests - #160627
Conversation
When encountering a move error caused by a desugared method call, talk about the user-facing feature (`await`/`?`/`for`-loop), instead of only the internal API it got desugared to.
```
error[E0382]: use of moved value: `entry`
--> $DIR/moved-into-question-mark.rs:11:18
|
LL | for entry in fs::read_dir(".")? {
| ----- move occurs because `entry` has type `Result<DirEntry, std::io::Error>`, which does not implement the `Copy` trait
LL |
LL | let file_type = entry?.file_type()?;
| ------ `entry` moved due to usage in the question mark operator
...
LL | dbg!(entry?.file_name());
| ^^^^^ value used here after move
|
note: the question mark operator is expanded into a call to `branch`, which takes ownership of the receiver `self`, which moves `entry`
--> $SRC_DIR/core/src/ops/try_trait.rs:LL:COL
help: you could `clone` the value and consume it, if the following trait bounds could be satisfied: `DirEntry: Clone` and `std::io::Error: Clone`
|
LL | let file_type = entry.clone()?.file_type()?;
| ++++++++
```
…` jobs
The aarch64 macos runners seem to be consistently among the slowest
jobs, sometimes pushing our overall CI time to 4 hours on a bad run.
Let's try to split the jobs to keep the overall Merge CI time
manageable:
* `aarch64-apple` => `aarch64-apple-{1,2}`
* `aarch64-apple-macos-26` => `aarch64-apple-macos-26-{1,2}`
This method currently does two things: it applies the effect, and also computes the edges. However: - Three of the four call sites don't use the edges. - Most analyses just return `terminator.edges()` unconditionally. This commit separates the edge computation into a new method, `get_terminator_edges()`. It defaults to `terminator.edges()`, which means that most analyses don't need to define it. And now edges are only obtained when they are needed (in `Forward::apply_effects_in_block`).
On Apple, `send`/`sendto` reject a length larger than `c_int::MAX` with `EINVAL` instead of doing a short send. The send length was only clamped to `wrlen_t::MAX` (a no-op on 64-bit unix), so writing more than `c_int::MAX` bytes to a socket failed on macOS. Add a `MAX_SEND_LEN` cap (`c_int::MAX` on Apple, `wrlen_t::MAX` elsewhere), used in `write`, `send`, `send_to`, and `send_with_flags`.
The pages are demand-zero and never written, so the datagram test no longer needs ~2 GiB of memory and its `#[ignore]` can go away. Keep a `Vec`-backed copy for non-unix targets, where `mmap` isn't available.
.. so that you don't need to import `TypeVisitable` in order to use it. I used the `TypeVisitable` from `rustc_type_ir` and not `rustc_middle::ty` because the macro is called inside `rustc_type_ir` itself.
This is a cheaper alternative to `TyAndLayout::for_variant(_, idx).is_uninhabited()`
.. instead of hand-rolling our own
these are slightly distinct subsets of a platonic ideal borrowck.
This comment has been minimized.
This comment has been minimized.
Rollup of 17 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-*
This comment has been minimized.
This comment has been minimized.
This comment was marked as outdated.
This comment was marked as outdated.
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 887804d (parent) -> 84b36a7 (this PR) Test differencesShow 67 test diffsStage 1
Stage 2
Additionally, 6 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 84b36a78a28a63f134171c670be1932ffa2485f8 --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: 887804d568 In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
|
Finished benchmarking commit (84b36a7): comparison URL. Overall result: ❌✅ regressions and improvements - please read:Our benchmarks found a performance regression caused by this PR. Next Steps:
@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.9%)A less reliable metric. May be of interest, but not used to determine the overall result above.
CyclesThis perf run didn't have relevant results for this metric. Binary sizeThis perf run didn't have relevant results for this metric. Bootstrap: 458.35s -> 457.798s (-0.12%) |
|
Started perf runs |
Successful merges:
aarch64-apple{,-macos-26}=>aarch64-apple{,-macos-26}-{1,2}jobs #160415 (Splitaarch64-apple{,-macos-26}=>aarch64-apple{,-macos-26}-{1,2}jobs)visible_parent_mapbreadth-first search #160464 (fix: Check the fallback map before queueing child invisible_parent_mapbreadth-first search)apply_primary_terminator_effect#160555 (Splitapply_primary_terminator_effect)#[unroll]=>#[rustc_unroll]to mitigate nameres ambiguity #160211 (Rename#[unroll]=>#[rustc_unroll]to mitigate nameres ambiguity)LayoutData::is_variant_uninhabitedmethod #160398 (rustc_abi: AddLayoutData::is_variant_uninhabitedmethod)VisitorResulthelper macros #160568 (UseVisitorResulthelper macros)r? @ghost
Create a similar rollup