- Round to zero, and representable values cast directly.
- `NaN` goes to 0
- Values beyond the limits of the type are saturated to the "nearest value"
(essentially rounding to zero, in some sense) in the integral type, so e.g.
`f32::INFINITY` would go to `{u,i}N::MAX.`
Rollup of 6 pull requests
Successful merges:
- #71510 (Btreemap iter intertwined)
- #71727 (SipHasher with keys initialized to 0 should just use new())
- #71889 (Explain our RwLock implementation)
- #71905 (Add command aliases from Cargo to x.py commands)
- #71914 (Backport 1.43.1 release notes to master)
- #71921 (explain the types used in the open64 call)
Failed merges:
r? @ghost
explain the types used in the open64 call
Fixes https://github.com/rust-lang/rust/issues/71915, where I learned about this quirk. I don't actually know what I am talking about here. ;)
Btreemap iter intertwined
3 commits:
1. Introduced benchmarks for `BTreeMap::iter()`. Benchmarks named `iter_20` were of the whole iteration process, so I renamed them. Also the benchmarks of `range` that I wrote earlier weren't very good. I included an (awkwardly named) one that compares `iter()` to `range(..)` on the same set, because the contrast is surprising:
```
name ns/iter
btree::map::range_unbounded_unbounded 28,176
btree::map::range_unbounded_vs_iter 89,369
```
Both dig up the same pair of leaf edges. `range(..)` also checks that some keys are correctly ordered, the only thing `iter()` does more is to copy the map's length.
2. Slightly refactoring the code to what I find more readable (not in chronological order of discovery), boosts performance:
```
>cargo-benchcmp.exe benchcmp a1 a2 --threshold 5
name a1 ns/iter a2 ns/iter diff ns/iter diff % speedup
btree::map::find_rand_100 18 17 -1 -5.56% x 1.06
btree::map::first_and_last_10k 64 71 7 10.94% x 0.90
btree::map::iter_0 2,939 2,209 -730 -24.84% x 1.33
btree::map::iter_1 6,845 2,696 -4,149 -60.61% x 2.54
btree::map::iter_100 8,556 3,672 -4,884 -57.08% x 2.33
btree::map::iter_10k 9,292 5,884 -3,408 -36.68% x 1.58
btree::map::iter_1m 10,268 6,510 -3,758 -36.60% x 1.58
btree::map::iteration_mut_100000 478,575 453,050 -25,525 -5.33% x 1.06
btree::map::range_unbounded_unbounded 28,176 36,169 7,993 28.37% x 0.78
btree::map::range_unbounded_vs_iter 89,369 38,290 -51,079 -57.16% x 2.33
btree::set::clone_100_and_remove_all 4,801 4,245 -556 -11.58% x 1.13
btree::set::clone_10k_and_remove_all 529,450 496,030 -33,420 -6.31% x 1.07
```
But you can tell from the `range_unbounded_*` lines that, despite an unwarranted, vengeful attack on the range_unbounded_unbounded benchmark, this change still doesn't allow `iter()` to catch up with `range(..)`.
3. I guess that `range(..)` copes so well because it intertwines the leftmost and rightmost descend towards leaf edges, doing the two root node accesses close together, perhaps exploiting a CPU's internal pipelining? So the third commit distils a version of `range_search` (which we can't use directly because of the `Ord` bound), and we get another boost:
```
cargo-benchcmp.exe benchcmp a2 a3 --threshold 5
name a2 ns/iter a3 ns/iter diff ns/iter diff % speedup
btree::map::first_and_last_100 40 43 3 7.50% x 0.93
btree::map::first_and_last_10k 71 64 -7 -9.86% x 1.11
btree::map::iter_0 2,209 1,719 -490 -22.18% x 1.29
btree::map::iter_1 2,696 2,205 -491 -18.21% x 1.22
btree::map::iter_100 3,672 2,943 -729 -19.85% x 1.25
btree::map::iter_10k 5,884 3,929 -1,955 -33.23% x 1.50
btree::map::iter_1m 6,510 5,532 -978 -15.02% x 1.18
btree::map::iteration_mut_100000 453,050 476,667 23,617 5.21% x 0.95
btree::map::range_included_excluded 405,075 371,297 -33,778 -8.34% x 1.09
btree::map::range_included_included 427,577 397,440 -30,137 -7.05% x 1.08
btree::map::range_unbounded_unbounded 36,169 28,175 -7,994 -22.10% x 1.28
btree::map::range_unbounded_vs_iter 38,290 30,838 -7,452 -19.46% x 1.24
```
But I think this is just fake news from the microbenchmarking media. `iter()` is still trying to catch up with `range(..)`. And we can sure do without another function. So I would skip this 3rd commit.
r? @Mark-Simulacrum
Update to rustc changes
changelog: none
So, turns out `git subtree push` dies in various interesting ways, but the source cause is that the rustc repo looks like
```
--- A --- B --- C ---
\--- D ---/
```
where `B` is the commit where I added clippy to rustc and `D` is an arbitrary other PR and `C` is the master branch (or an earlier commit in it). When we now do `git subtree push`, it doesn't stop looking for things to merge at `B` as it needs to look at `D`, too, but then the bad thing happens, and it doesn't stop at `A` either, and just goes on looking at the entire history of rustc in a recursive bash script. That recursion then quickly runs into a stack overflow. While we can increase the stack size via `ulimit -s 60000`, that just means I was waiting for 30 minutes looking at `git subtree push` counting up the number of commits it has looked at. I aborted that, as a process that needs 30 mins for a push is not reasonable.
This PR cheats by just doing a `cp -r ../rustc/src/tools/clippy/* .` inside my clippy checkout and committing all changes. I'm working on getting us a better workflow, but until then, this workaround will work nicely. Note that this requires a `git subrepo pull` to have occurred in the `rustc` checkout. It's not necessary to merge that pull in order to update clippy, it's just necessary in order to not revert code in the clippy repo that hasn't been synced yet to the rustc repo.
perf: Unify the undo log of all snapshot types
Extracted from #69218 and extended to all the current snapshot types.
Since snapshotting is such a frequent action in the compiler and many of the scopes execute so little work, the act of creating the snapshot and rolling back empty/small snapshots end up showing in perf. By unifying all the logs into one the creation of snapshots becomes significantly cheaper at the cost of some complexity when combining the log with the specific data structures that are being mutated.
Depends on https://github.com/rust-lang-nursery/ena/pull/29
This commit adds some new `LocalDecl` methods:
- `with_source_info`, a most general constructor.
- `new`, a variant of `with_source_info` which represents the most
common use case.
- `internal` a modifying method (like the already present `immutable`).
It removes some old `LocalDecl` methods:
- `new_internal` and `new_local`, because they're subsumed by the new
methods.
- `new_return_place`, because it was identical to `new_temp`.
Finally, it cleans up all the use sites.
Update RLS
In addition to fixing the toolstate, this also changes the default
compilation model to the out-of-process one, which should hopefully
target considerable memory usage for long-running instances of the RLS.
Fixes#71753
r? @ghost
We don't want to export any symbols from Rust's version of libunwind
as these may collide with other copies of libunwind e.g. when linking
Rust staticlib together C/C++ libraries that have their own version.
In addition to fixing the toolstate, this also changes the default
compilation model to the out-of-process one, which should hopefully
target considerable memory usage for long-running instances of the RLS.
Rollup of 4 pull requests
Successful merges:
- #69984 (Add Option to Force Unwind Tables)
- #71830 (Remove clippy from some leftover lists of "possibly failing" tools)
- #71894 (Suggest removing semicolon in last expression only if it's type is known)
- #71897 (Improve docs for embed-bitcode and linker-plugin-lto)
Failed merges:
r? @ghost
Suggest removing semicolon in last expression only if it's type is known
Fixes#67971
Is there a syntax for explicitly checking if a note doesn't exist in test output? Something like `//~ !NOTE ...`
I believe r? @estebank deals with diagnostics.
