| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
|
|
|
|
Because they are small and hot.
|
|
It's never used in a meaningful way.
|
|
|
|
stabilize RangeBounds collections_range #30877
The FCP for #30877 closed last month, with the decision to:
1. move from `collections::range::RangeArgument` to `ops::RangeBounds`, and
2. rename `start()` and `end()` to `start_bounds()` and `end_bounds()`.
Simon Sapin already moved it to `ops::RangeBounds` in #49163.
I renamed the functions, and removed the old `collections::range::RangeArgument` alias.
This is my first Rust PR, please let me know if I can improve anything. This passes all tests for me, except the `clippy` tool (which uses `RangeArgument::start()`).
I considered deprecating `start()` and `end()` instead of removing them, but the contribution guidelines indicate we can break `clippy` temporarily. I thought it was best to remove the functions, since we're worried about name collisions with `Range::start` and `end`.
Closes #30877.
|
|
implement the chalk-engine traits
Preliminary implementation for the Chalk traits in rustc. Lots of `panic!()` placeholders to be filled in later.
This is currently blocked on us landing https://github.com/rust-lang-nursery/chalk/pull/131 in chalk and issuing a new release, which should occur later today.
r? @scalexm
cc @leodasvacas
|
|
|
|
rename RangeBounds::start() -> start_bound()
rename RangeBounds::end() -> end_bound()
|
|
|
|
|
|
|
|
order which lookup relies on.
|
|
|
|
|
|
|
|
Rollup of 10 pull requests
Successful merges:
- #50387 (Remove leftover tab in libtest outputs)
- #50553 (Add Option::xor method)
- #50610 (Improve format string errors)
- #50649 (Tweak `nearest_common_ancestor()`.)
- #50790 (Fix grammar documentation wrt Unicode identifiers)
- #50791 (Fix null exclusions in grammar docs)
- #50806 (Add `bless` x.py subcommand for easy ui test replacement)
- #50818 (Speed up `opt_normalize_projection_type`)
- #50837 (Revert #49767)
- #50839 (Make sure people know the book is free oline)
Failed merges:
|
|
stop considering location when computing outlives relationships
This doesn't (yet?) use SEME regions, but it does ignore the location for outlives constraints. This makes (I believe) NLL significantly faster -- but we should do some benchmarks. It regresses the "get-default" family of use cases for NLL, which is a shame, but keeps the other benefits, and thus represents a decent step forward.
r? @pnkfelix
|
|
Speed up `opt_normalize_projection_type`
`opt_normalize_projection_type` is hot in the serde and futures benchmarks in rustc-perf. These two patches speed up the execution of most runs for them by 2--4%.
|
|
There is a hot path through `opt_normalize_projection_type`:
- `try_start` does a cache lookup (#1).
- The result is a `NormalizedTy`.
- There are no unresolved type vars, so we call `complete`.
- `complete` does *another* cache lookup (#2), then calls
`SnapshotMap::insert`.
- `insert` does *another* cache lookup (#3), inserting the same value
that's already in the cache.
This patch optimizes this hot path by introducing `complete_normalized`,
for use when the value is known in advance to be a `NormalizedTy`. It
always avoids lookup #2. Furthermore, if the `NormalizedTy`'s
obligations are empty (the common case), we know that lookup #3 would be
a no-op, so we avoid it, while inserting a Noop into the `SnapshotMap`'s
undo log.
|
|
Stabilize num::NonZeroU*
Tracking issue: https://github.com/rust-lang/rust/issues/49137
|
|
Tracking issue: https://github.com/rust-lang/rust/issues/49137
|
|
It was introduced in #50240 to avoid an allocation when creating a new
BTreeMap, which gave some speed-ups. But then #50352 made that the
default behaviour for BTreeMap, so LazyBTreeMap is no longer necessary.
|
|
|
|
|
|
|
|
|
|
Implement LazyBTreeMap and use it in a few places.
This is a thin wrapper around BTreeMap that avoids allocating upon creation.
I would prefer to change BTreeMap directly to make it lazy (like I did with HashSet in #36734) and I initially attempted that by making BTreeMap::root an Option<>. But then I also had to change Iter and Range to handle trees with no root, and those types have stability markers on them and I wasn't sure if that was acceptable. Also, BTreeMap has a lot of complex code and changing it all was challenging, and I didn't have high confidence about my general approach.
So I prototyped this wrapper instead and used it in the hottest locations to get some measurements about the effect. The measurements are pretty good!
- Doing a debug build of serde, it reduces the total number of heap allocations from 17,728,709 to 13,359,384, a 25% reduction. The number of bytes allocated drops from 7,474,672,966 to 5,482,308,388, a 27% reduction.
- It gives speedups of up to 3.6% on some rustc-perf benchmark jobs. crates.io, futures, and serde benefit most.
```
futures-check
avg: -1.9% min: -3.6% max: -0.5%
serde-check
avg: -2.1% min: -3.5% max: -0.7%
crates.io-check
avg: -1.7% min: -3.5% max: -0.3%
serde
avg: -2.0% min: -3.0% max: -0.9%
serde-opt
avg: -1.8% min: -2.9% max: -0.3%
futures
avg: -1.5% min: -2.8% max: -0.4%
tokio-webpush-simple-check
avg: -1.1% min: -2.2% max: -0.1%
futures-opt
avg: -1.2% min: -2.1% max: -0.4%
piston-image-check
avg: -0.8% min: -1.1% max: -0.3%
crates.io
avg: -0.6% min: -1.0% max: -0.3%
```
@Gankro, how do you think I should proceed here? Is leaving this as a wrapper reasonable? Or should I try to make BTreeMap itself lazy? If so, can I change the representation of Iter and Range?
Thanks!
|
|
|
|
This is a thin wrapper around BTreeMap that avoids allocating upon
creation. It speeds up some rustc-perf benchmarks by up to 3.6%.
|
|
Replace manual iterator exhaust with for_each(drop)
This originally added a dedicated method, `Iterator::exhaust`, and has since been replaced with `for_each(drop)`, which is more idiomatic.
<del>This is just shorthand for `for _ in &mut self {}` or `while let Some(_) = self.next() {}`. This states the intent a lot more clearly than the identical code: run the iterator to completion.
<del>At least personally, my eyes tend to gloss over `for _ in &mut self {}` without fully paying attention to what it does; having a `Drop` implementation akin to:
<del>`for _ in &mut self {}; unsafe { free(self.ptr); }`</del>
<del>Is not as clear as:
<del>`self.exhaust(); unsafe { free(self.ptr); }`
<del>Additionally, I've seen debate over whether `while let Some(_) = self.next() {}` or `for _ in &mut self {}` is more clear, whereas `self.exhaust()` is clearer than both.
|
|
Even more thread-safety changes
r? @michaelwoerister
|
|
Move deny(warnings) into rustbuild
This permits easier iteration without having to worry about warnings
being denied.
Fixes #49517
|
|
|
|
|
|
|
|
More thread-safety changes
r? @michaelwoerister
|
|
This permits easier iteration without having to worry about warnings
being denied.
Fixes #49517
|
|
Holy cow that's a lot of `cfg(stage0)` removed and a lot of new stable language
features!
|
|
|
|
This makes sure that all bits in each IdxSet between the universe length
and the end of the word are all zero instead of being in an indeterminate state.
This fixes a crash with RUST_LOG=rustc_mir, and is probably a good idea
anyway.
|
|
Implement some trivial size_hints for various iterators
This also implements ExactSizeIterator where applicable.
Addresses most of the Iterator traits mentioned in #23708.
I intend to do more, but I don't want to make the PR too large.
|
|
These unstable items are deprecated:
* The `std::collections::range::RangeArgument` reexport
* The `std::collections::range` module.
|
|
The stable reexport `std::collections::Bound` is now deprecated.
Another deprecated reexport could be added in `alloc`,
but that crate is unstable.
|
|
|
|
|
|
|
|
|
