RangeInclusive internal iteration performance improvement.
Specialize `Iterator::try_fold` and `DoubleEndedIterator::try_rfold` to improve code generation in all internal iteration scenarios.
This changes brings the performance of internal iteration with `RangeInclusive` on par with the performance of iteration with `Range`:
- Single conditional jump in hot loop,
- Unrolling and vectorization,
- And even Closed Form substitution.
Unfortunately, it only applies to internal iteration. Despite various attempts at stream-lining the implementation of `next` and `next_back`, LLVM has stubbornly refused to optimize external iteration appropriately, leaving me with a choice between:
- The current implementation, for which Closed Form substitution is performed, but which uses 2 conditional jumps in the hot loop when optimization fail.
- An implementation using a `is_done` boolean, which uses 1 conditional jump in the hot loop when optimization fail, allowing unrolling and vectorization, but for which Closed Form substitution fails.
In the absence of any conclusive evidence as to which usecase matters most, and with no assurance that the lack of Closed Form substitution is not indicative of other optimizations being foiled, there is no way
to pick one implementation over the other, and thus I defer to the statu quo as far as `next` and `next_back` are concerned.
Rollup of 17 pull requests
Successful merges:
- #57656 (Deprecate the unstable Vec::resize_default)
- #58059 (deprecate before_exec in favor of unsafe pre_exec)
- #58064 (override `VecDeque::try_rfold`, also update iterator)
- #58198 (Suggest removing parentheses surrounding lifetimes)
- #58431 (fix overlapping references in BTree)
- #58555 (Add a note about 2018e if someone uses `try {` in 2015e)
- #58588 (remove a bit of dead code)
- #58589 (cleanup macro after 2018 transition)
- #58591 (Dedup a rustdoc diagnostic construction)
- #58600 (fix small documentation typo)
- #58601 (Search for target_triple.json only if builtin target not found)
- #58606 (Docs: put Future trait into spotlight)
- #58607 (Fixes#58586: Make E0505 erronous example fail for the 2018 edition)
- #58615 (miri: explain why we use static alignment in ref-to-place conversion)
- #58620 (introduce benchmarks of BTreeSet.intersection)
- #58621 (Update miri links)
- #58632 (Make std feature list sorted)
Failed merges:
r? @ghost
introduce benchmarks of BTreeSet.intersection
16 tests combining 4 kinds of contents with different sizes exposing edge cases.
The ones with asymmetric sizes are addressed by https://github.com/rust-lang/rust/pull/58577.
The pos_vs_neg cases seems (are were meant to be) the same as the neg_vs_pos case (same thing, reverse order) but reality shows a surprsing 25% difference.
miri: explain why we use static alignment in ref-to-place conversion
@eddyb @oli-obk do you think this makes sense? Or should we use the run-time alignment (`align_of_val`)? I am a bit worried about custom DSTs, but that affects way more areas of Miri so I'd ignore them for now.
r? @oli-obk
Docs: put Future trait into spotlight
If a function returns a type that implements `Future`, there should be a small "i" symbol next to it indicating the return type implements an important trait.
Search for target_triple.json only if builtin target not found
Before this commit, if the builtin target was found, but an error
happened when instantiating it (e.g. validating the target
specification file failed, etc.), then we ignored those errors
and proceeded to try to find a `target_triple.json` file, and if
that failed, reported that as an error.
With this commit, if rustc is supposed to provide the builtin target,
and something fails while instantiating it, that error will
get properly propagated.
r? @oli-obk
Add a note about 2018e if someone uses `try {` in 2015e
Inspired by https://github.com/rust-lang/rust/issues/58491, where a `try_blocks` example was accidentally run in 2015, which of course produces a bunch of errors.
What's the philosophy about gating for this? The keyword is stably a keyword in 2018, so I haven't gated it for now but am not mentioning what the keyword _does_. Let me know if I should do differently.
Resolves#53672
fix overlapping references in BTree
This fixes two kinds of overlapping references in BTree (both found by running the BTree test suite in Miri).
In `into_slices_mut`, we did `k.into_key_slice_mut()` followed by `self.into_val_slice_mut()` (where `k` is a copy of `self`). Calling `into_val_slice_mut` calls `self.len()`, which creates a shared reference to `NodeHeader`, which unfortunately (due to padding) overlaps with the mutable reference returned by `into_key_slice_mut`. Hence the key slice got (partially) invalidated. The fix is to avoid creating an `&NodeHeader` after the first slice got created.
In the iterators, we used to first create the references that will be returned, and then perform the walk on the tree. Walking the tree creates references (such as `&mut InternalNode`) that overlap with all of the keys and values stored in a pointer; in particular, they overlap with the references the iterator will later return. This is fixed by reordering the operations of walking the tree and obtaining the inner references.
The test suite still passes (and it passes in Miri now!), but there is a lot of code here that I do not understand...
override `VecDeque::try_rfold`, also update iterator
This keeps the slice based iteration and updates the iterator state after each slice. It also uses a loop to reduce the amount of code.
This uses unsafe code, so some thorough review would be appreciated. Cc @RalfJung
improve Pin documentation
Incorporates a bunch of the documentation-related comments that came up when discussing `Pin` stabilization.
Cc @alexcrichton @withoutboats @cramertj @jonhoo
Fixes https://github.com/rust-lang/rust/issues/58130
Re-implement leak check in terms of universes
This PR temporarily restores the leak-check, but implemented in terms of universes. This is not because the leak check behavior was necessarily **correct**, but because (a) we may want to have a transition period and because (b) we want to have more breathing room to work through the full implications of handling higher-ranked types correctly. Note that this PR builds atop https://github.com/rust-lang/rust/pull/58056.
Fixes#58451Fixes#46989Fixes#57639
r? @aturon
cc @arielb1, @lqd
~~Temporary note: I've not finished running `./x.py test` locally -- I'm confident a lot of error messages in tests will need updating. I sort of expect them to revert to the older, (imo) less good error messages, which is mildly unfortunate. There might be a way to preserve the new error messages, not sure.~~
Update cargo
9 commits in 865cb70106a6b1171a500ff68f93ab52eea56e72..b33ce7fc9092962b0657b4c25354984b5e5c47e4
2019-02-10 15:49:37 +0000 to 2019-02-19 18:42:50 +0000
- Don't retry invalid credentials from git credential helpers (rust-lang/cargo#6681)
- Fix some typos in resolver tests (rust-lang/cargo#6682)
- Add an unstable option to build proc macros for both the host and the target (rust-lang/cargo#6547)
- Test cases proving RUSTC_WRAPPER can be a relative path (rust-lang/cargo#6638)
- Add support for Azure DevOps (rust-lang/cargo#6264)
- Update docs for removed `patch` restriction. (rust-lang/cargo#6663)
- Fix incorrect help message (rust-lang/cargo#6555)
- Stabilize Alternative Registries (rust-lang/cargo#6654)
- Having a [patch] section when publishing is not an error (rust-lang/cargo#6535)
Mazdak Farrokhzad