Remove Stacked Borrows GC heuristics
Removing these has no impact on our benchmarks. I think I initially added these because they have a significant impact on runtime at shorter GC intervals. But both these heuristics result in undesirable memory growth in real programs, especially `modified_since_last_gc`. I didn't realize at the time that required state becomes garbage as a result of changes to _other_ allocations.
I think this nets even primarily because we get better heap reuse. With this change I see almost all the mmap calls coming from our diagnostics infrastructure go away. Not that there were many to start with, but it's an indicator that our memory locality has improved.
Before:
```
Benchmark 1: cargo miri run --manifest-path "/home/ben/miri/bench-cargo-miri/backtraces/Cargo.toml"
Time (mean ± σ): 4.046 s ± 0.087 s [User: 3.952 s, System: 0.085 s]
Range (min … max): 3.952 s … 4.139 s 5 runs
Benchmark 1: cargo miri run --manifest-path "/home/ben/miri/bench-cargo-miri/invalidate/Cargo.toml"
Time (mean ± σ): 6.271 s ± 0.073 s [User: 6.206 s, System: 0.054 s]
Range (min … max): 6.195 s … 6.365 s 5 runs
Benchmark 1: cargo miri run --manifest-path "/home/ben/miri/bench-cargo-miri/mse/Cargo.toml"
Time (mean ± σ): 570.3 ms ± 6.7 ms [User: 505.5 ms, System: 61.8 ms]
Range (min … max): 559.6 ms … 576.0 ms 5 runs
Benchmark 1: cargo miri run --manifest-path "/home/ben/miri/bench-cargo-miri/serde1/Cargo.toml"
Time (mean ± σ): 2.013 s ± 0.012 s [User: 1.938 s, System: 0.069 s]
Range (min … max): 1.994 s … 2.024 s 5 runs
Benchmark 1: cargo miri run --manifest-path "/home/ben/miri/bench-cargo-miri/serde2/Cargo.toml"
Time (mean ± σ): 4.155 s ± 0.082 s [User: 4.078 s, System: 0.067 s]
Range (min … max): 4.011 s … 4.211 s 5 runs
Benchmark 1: cargo miri run --manifest-path "/home/ben/miri/bench-cargo-miri/slice-get-unchecked/Cargo.toml"
Time (mean ± σ): 541.5 ms ± 3.9 ms [User: 477.3 ms, System: 60.0 ms]
Range (min … max): 536.1 ms … 545.1 ms 5 runs
Benchmark 1: cargo miri run --manifest-path "/home/ben/miri/bench-cargo-miri/unicode/Cargo.toml"
Time (mean ± σ): 1.496 s ± 0.002 s [User: 1.442 s, System: 0.050 s]
Range (min … max): 1.494 s … 1.500 s 5 runs
Benchmark 1: cargo miri run --manifest-path "/home/ben/miri/bench-cargo-miri/zip-equal/Cargo.toml"
Time (mean ± σ): 2.190 s ± 0.043 s [User: 2.109 s, System: 0.075 s]
Range (min … max): 2.114 s … 2.215 s 5 runs
```
After:
```
Benchmark 1: cargo miri run --manifest-path "/home/ben/miri/bench-cargo-miri/backtraces/Cargo.toml"
Time (mean ± σ): 3.954 s ± 0.057 s [User: 3.871 s, System: 0.075 s]
Range (min … max): 3.912 s … 4.052 s 5 runs
Benchmark 1: cargo miri run --manifest-path "/home/ben/miri/bench-cargo-miri/invalidate/Cargo.toml"
Time (mean ± σ): 6.200 s ± 0.108 s [User: 6.129 s, System: 0.060 s]
Range (min … max): 6.072 s … 6.295 s 5 runs
Benchmark 1: cargo miri run --manifest-path "/home/ben/miri/bench-cargo-miri/mse/Cargo.toml"
Time (mean ± σ): 575.3 ms ± 9.3 ms [User: 511.5 ms, System: 60.2 ms]
Range (min … max): 558.9 ms … 580.8 ms 5 runs
Benchmark 1: cargo miri run --manifest-path "/home/ben/miri/bench-cargo-miri/serde1/Cargo.toml"
Time (mean ± σ): 1.966 s ± 0.007 s [User: 1.903 s, System: 0.058 s]
Range (min … max): 1.959 s … 1.974 s 5 runs
Benchmark 1: cargo miri run --manifest-path "/home/ben/miri/bench-cargo-miri/serde2/Cargo.toml"
Time (mean ± σ): 4.138 s ± 0.040 s [User: 4.057 s, System: 0.072 s]
Range (min … max): 4.110 s … 4.207 s 5 runs
Benchmark 1: cargo miri run --manifest-path "/home/ben/miri/bench-cargo-miri/slice-get-unchecked/Cargo.toml"
Time (mean ± σ): 541.8 ms ± 5.6 ms [User: 470.7 ms, System: 66.9 ms]
Range (min … max): 535.6 ms … 549.1 ms 5 runs
Benchmark 1: cargo miri run --manifest-path "/home/ben/miri/bench-cargo-miri/unicode/Cargo.toml"
Time (mean ± σ): 1.490 s ± 0.021 s [User: 1.424 s, System: 0.060 s]
Range (min … max): 1.454 s … 1.505 s 5 runs
Benchmark 1: cargo miri run --manifest-path "/home/ben/miri/bench-cargo-miri/zip-equal/Cargo.toml"
Time (mean ± σ): 2.215 s ± 0.048 s [User: 2.113 s, System: 0.072 s]
Range (min … max): 2.183 s … 2.299 s 5 runs
```
Rollup of 6 pull requests
Successful merges:
- #118193 (Add missing period in `std::process::Command` docs)
- #118222 (unify read_to_end and io::copy impls for reading into a Vec)
- #118323 (give dev-friendly error message for incorrect config profiles)
- #118378 (Perform LTO optimisations with wasm-ld + -Clinker-plugin-lto)
- #118399 (Clean dead codes in miri)
- #118410 (update test for new LLVM 18 codegen)
r? `@ghost`
`@rustbot` modify labels: rollup
[`redundant_closure_call`]: avoid duplicated `async` keyword when triggering on closure that returns `async` block
close#11357
----
*Please write a short comment explaining your change (or "none" for internal only changes)*
changelog: [`redundant_closure_call`]: avoid duplicated `async` keyword when triggering on closure that returns `async` block
Validation introduced in #113124 allows UnwindAction::Continue and
TerminatorKind::Resume to occur only in functions with ABI that can
unwind. The function ABI depends on the panic strategy, which can vary
across crates.
Usually MIR is built and validated in the same crate. The coroutine drop
glue thus far was an exception. As a result validation could fail when
mixing different panic strategies.
Avoid the problem by executing AbortUnwindingCalls along with the
validation.
When encountering a bare assignment in a let-chain, suggest turning the
assignment into a `let` expression or an equality check.
```
error: expected expression, found `let` statement
--> $DIR/bad-if-let-suggestion.rs:5:8
|
LL | if let x = 1 && i = 2 {}
| ^^^^^^^^^
|
= note: only supported directly in conditions of `if` and `while` expressions
help: you might have meant to continue the let-chain
|
LL | if let x = 1 && let i = 2 {}
| +++
help: you might have meant to compare for equality
|
LL | if let x = 1 && i == 2 {}
| +
```
Perform LTO optimisations with wasm-ld + -Clinker-plugin-lto
Fixes (partially) #60059. Technically, `--target wasm32-unknown-unknown -Clinker-plugin-lto` would complete without errors before, but it was not producing optimized code. At least, it may have been but it was probably not the opt-level people intended.
Similarly to #118377, this could benefit from a warning about using an explicit libLTO path with LLD, which will ignore it and use its internal LLVM. Especially given we always use lld on wasm targets. I left the code open to that possibility rather than making it perfectly neat.
give dev-friendly error message for incorrect config profiles
before this change, an incorrect profile would result in the following error:
```sh
...
...
File "/home/nimda/devspace/onur-ozkan/rust/src/bootstrap/bootstrap.py", line 1088, in bootstrap
with open(include_path) as included_toml:
^^^^^^^^^^^^^^^^^^
FileNotFoundError: [Errno 2] No such file or directory: '/home/nimda/devspace/onur-ozkan/rust/src/bootstrap/defaults/config.aaaa.toml'
```
with this change, the error message is now:
```sh
...
...
File "/home/nimda/devspace/onur-ozkan/rust/src/bootstrap/bootstrap.py", line 1088, in bootstrap
raise Exception("Unrecognized profile '{}'. Check src/bootstrap/defaults"
Exception: Unrecognized profile 'aaaa'. Check src/bootstrap/defaults for available options.
```
unify read_to_end and io::copy impls for reading into a Vec
This ports over the initial probe (to avoid allocation) and the dynamic read sizing from the io::copy specialization to the `default_read_to_end` implementation which already had its own optimizations for different cases.
I think it should be a best-of-both now.
suggested by `@a1phyr` in https://github.com/rust-lang/rust/pull/117576#issuecomment-1803408492
Expand in-place iteration specialization to Flatten, FlatMap and ArrayChunks
This enables the following cases to collect in-place:
```rust
let v = vec![[0u8; 4]; 1024]
let v: Vec<_> = v.into_iter().flatten().collect();
let v: Vec<Option<NonZeroUsize>> = vec![NonZeroUsize::new(0); 1024];
let v: Vec<_> = v.into_iter().flatten().collect();
let v = vec![u8; 4096];
let v: Vec<_> = v.into_iter().array_chunks::<4>().collect();
```
Especially the nicheful-option-flattening should be useful in real code.
Fix comments for unsigned non-zero `checked_add`, `saturating_add`
While looking at #118313, I happened to notice that two of the expanded comments appear to be slightly inaccurate.
For these two methods, `other` is an ordinary unsigned integer, so it can be zero.
Since the sum of non-zero and zero is always non-zero, the safety argument holds even when `other` is zero.
Update mod comment
The comment of `ASCII_CASE_MASK` on line 477 is `If 6th bit is set ascii is lower case.` but the original comment of `*self ^ ((self.is_ascii_lowercase() as u8) * ASCII_CASE_MASK)` was `Toggle the fifth bit if this is a lowercase letter`
effects: Run `enforce_context_effects` for all method calls
So that we also perform checks when overloaded `PartialEq`s are called.
r? `@compiler-errors`
