| Age | Commit message (Collapse) | Author | Lines |
|
`HybridIdxSet` tweaks
A couple of tweaks to `HybridIdxSet`.
r? @nikomatsakis
|
|
Lazier sparse bit matrix
A small NLL win.
r? @nikomatsakis
|
|
|
|
They let `union()`, `union_sparse()` and `union_hybrid()` be merged.
Likewise for subtract()`, `subtract_sparse()` and `subtract_hybrid()`.
|
|
Because `domain` is a more obvious term than `universe` for this
concept.
|
|
|
|
Currently when a row is instantiated in SparseBitMatrix, any missing
rows prior to it are also fully instantiated.
This patch changes things so that those prior rows are minimally
instantiated (with a `None`). This avoids a decent number of allocations
in NLL, speeding up several benchmarks by up to 0.5%.
The patch also removes two unused methods, `len()` and
`iter_enumerated()`.
|
|
|
|
The new names are clearer.
|
|
Merge `IdxSet` and `IdxSetBuf`
Because it simplifies things.
@r? nikomatsakis
|
|
Replace usages of ptr::offset with ptr::{add,sub}.
Rust provides these helper methods – so let's use them!
|
|
Fix typos found by codespell.
|
|
|
|
Now that the `Buf` vs. non-`Buf` distinction has been removed, it makes
sense to drop the `Buf` suffix and use the shorter names everywhere.
|
|
The `Buf` vs. non-`Buf` distinction is no longer necessary, and the
nastiest code in this file can be removed.
To minimize this patch, `IdxSet` is made a typedef of `IdxSetBuf`. The
next patch will remove this typedef.
|
|
|
|
|
|
|
|
Speed up NLL with HybridIdxSetBuf.
It's a sparse-when-small but dense-when-large index set that is very
efficient for sets that (a) have few elements, (b) have large
universe_size values, and (c) are cleared frequently. Which makes it
perfect for the `gen_set` and `kill_set` sets used by the new borrow
checker.
This patch reduces `tuple-stress`'s NLL-check time by 40%, and up to 12%
for several other benchmarks. And it halves the max-rss for `keccak`,
and has smaller wins for `inflate` and `clap-rs`.
|
|
`HybridIdxSetBuf` is a sparse-when-small but dense-when-large index set
that is very efficient for sets that (a) have few elements, (b) have
large `universe_size` values, and (c) are cleared frequently. Which
makes it perfect for the `gen_set` and `kill_set` sets used by the new
borrow checker.
This patch reduces the execution time of the five slowest NLL benchmarks
by 55%, 21%, 16%, 10% and 9%. It also reduces the max-rss of three
benchmarks by 53%, 33%, and 9%.
|
|
use ? to simplify `TransitiveRelation.maybe_map`
I think this looks much clearer than the original.
|
|
|
|
|
|
Avoid many allocations for CStrings during codegen.
Giving in to my irrational fear of dynamic allocations. Let's see what perf says to this.
|
|
[nll] enable feature(nll) on various crates for bootstrap: part 4
#53172
r? @nikomatsakis
|
|
A few cleanups for rustc_data_structures
- remove a redundant `clone()`
- make some calls to `.iter()` implicit
- collapse/simplify a few operations
- remove some explicit `return`s
- make `SnapshotMap::{commit, rollback_to}` take references
- remove unnecessary struct field names
- change `transmute()`s in `IdxSet::{from_slice, from_slice_mut}` to casts
- remove some unnecessary lifetime annotations
- split 2 long literals
|
|
Don't collect() when size_hint is useless
This adjusts PRs #52738 and #52697 by falling back to calculating capacity and extending or pushing in a loop where `collect()` can't be trusted to calculate the right capacity.
It is a performance win.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Add errors for unknown, stable and duplicate feature attributes
- Adds an error for unknown (lang and lib) features.
- Extends the lint for unnecessary feature attributes for stable features to libs features (this already exists for lang features).
- Adds an error for duplicate (lang and lib) features.
```rust
#![feature(fake_feature)] //~ ERROR unknown feature `fake_feature`
#![feature(i128_type)] //~ WARNING the feature `i128_type` has been stable since 1.26.0
#![feature(non_exhaustive)]
#![feature(non_exhaustive)] //~ ERROR duplicate `non_exhaustive` feature attribute
```
Fixes #52053, fixes #53032 and address some of the problems noted in #44232 (though not unused features).
There are a few outstanding problems, that I haven't narrowed down yet:
- [x] Stability attributes on macros do not seem to be taken into account.
- [x] Stability attributes behind `cfg` attributes are not taken into account.
- [x] There are failing incremental tests.
|
|
|
|
|
|
also add benchmarks
Before:
```
test tiny_list::test::bench_insert_empty ... bench: 1 ns/iter (+/- 0)
test tiny_list::test::bench_insert_one ... bench: 16 ns/iter (+/- 0)
test tiny_list::test::bench_remove_empty ... bench: 2 ns/iter (+/- 0)
test tiny_list::test::bench_remove_one ... bench: 6 ns/iter (+/- 0)
test tiny_list::test::bench_remove_unknown ... bench: 4 ns/iter (+/- 0)
```
After:
```
test tiny_list::test::bench_insert_empty ... bench: 1 ns/iter (+/- 0)
test tiny_list::test::bench_insert_one ... bench: 16 ns/iter (+/- 0)
test tiny_list::test::bench_remove_empty ... bench: 0 ns/iter (+/- 0)
test tiny_list::test::bench_remove_one ... bench: 3 ns/iter (+/- 0)
test tiny_list::test::bench_remove_unknown ... bench: 2 ns/iter (+/- 0)
```
|
|
Another SmallVec.extend optimization
This improves SmallVec.extend even more over #52859 while making the code easier to read.
Before
```
test small_vec::tests::fill_small_vec_1_10_with_cap ... bench: 31 ns/iter (+/- 5)
test small_vec::tests::fill_small_vec_1_10_wo_cap ... bench: 70 ns/iter (+/- 4)
test small_vec::tests::fill_small_vec_1_50_with_cap ... bench: 36 ns/iter (+/- 3)
test small_vec::tests::fill_small_vec_1_50_wo_cap ... bench: 256 ns/iter (+/- 17)
test small_vec::tests::fill_small_vec_32_10_with_cap ... bench: 31 ns/iter (+/- 5)
test small_vec::tests::fill_small_vec_32_10_wo_cap ... bench: 26 ns/iter (+/- 1)
test small_vec::tests::fill_small_vec_32_50_with_cap ... bench: 49 ns/iter (+/- 4)
test small_vec::tests::fill_small_vec_32_50_wo_cap ... bench: 219 ns/iter (+/- 11)
test small_vec::tests::fill_small_vec_8_10_with_cap ... bench: 32 ns/iter (+/- 2)
test small_vec::tests::fill_small_vec_8_10_wo_cap ... bench: 61 ns/iter (+/- 12)
test small_vec::tests::fill_small_vec_8_50_with_cap ... bench: 37 ns/iter (+/- 3)
test small_vec::tests::fill_small_vec_8_50_wo_cap ... bench: 210 ns/iter (+/- 10)
```
After:
```
test small_vec::tests::fill_small_vec_1_10_wo_cap ... bench: 31 ns/iter (+/- 3)
test small_vec::tests::fill_small_vec_1_50_with_cap ... bench: 39 ns/iter (+/- 4)
test small_vec::tests::fill_small_vec_1_50_wo_cap ... bench: 35 ns/iter (+/- 4)
test small_vec::tests::fill_small_vec_32_10_with_cap ... bench: 37 ns/iter (+/- 3)
test small_vec::tests::fill_small_vec_32_10_wo_cap ... bench: 32 ns/iter (+/- 2)
test small_vec::tests::fill_small_vec_32_50_with_cap ... bench: 52 ns/iter (+/- 4)
test small_vec::tests::fill_small_vec_32_50_wo_cap ... bench: 46 ns/iter (+/- 0)
test small_vec::tests::fill_small_vec_8_10_with_cap ... bench: 35 ns/iter (+/- 4)
test small_vec::tests::fill_small_vec_8_10_wo_cap ... bench: 31 ns/iter (+/- 0)
test small_vec::tests::fill_small_vec_8_50_with_cap ... bench: 40 ns/iter (+/- 15)
test small_vec::tests::fill_small_vec_8_50_wo_cap ... bench: 36 ns/iter (+/- 2)
```
|
|
|
|
This improves SmallVec.extend even more over #52859
Before (as of #52859):
```
test small_vec::tests::fill_small_vec_1_10_with_cap ... bench: 31 ns/iter (+/- 5)
test small_vec::tests::fill_small_vec_1_10_wo_cap ... bench: 70 ns/iter (+/- 4)
test small_vec::tests::fill_small_vec_1_50_with_cap ... bench: 36 ns/iter (+/- 3)
test small_vec::tests::fill_small_vec_1_50_wo_cap ... bench: 256 ns/iter (+/- 17)
test small_vec::tests::fill_small_vec_32_10_with_cap ... bench: 31 ns/iter (+/- 5)
test small_vec::tests::fill_small_vec_32_10_wo_cap ... bench: 26 ns/iter (+/- 1)
test small_vec::tests::fill_small_vec_32_50_with_cap ... bench: 49 ns/iter (+/- 4)
test small_vec::tests::fill_small_vec_32_50_wo_cap ... bench: 219 ns/iter (+/- 11)
test small_vec::tests::fill_small_vec_8_10_with_cap ... bench: 32 ns/iter (+/- 2)
test small_vec::tests::fill_small_vec_8_10_wo_cap ... bench: 61 ns/iter (+/- 12)
test small_vec::tests::fill_small_vec_8_50_with_cap ... bench: 37 ns/iter (+/- 3)
test small_vec::tests::fill_small_vec_8_50_wo_cap ... bench: 210 ns/iter (+/- 10)
```
After:
```
test small_vec::tests::fill_small_vec_1_10_wo_cap ... bench: 31 ns/iter (+/- 3)
test small_vec::tests::fill_small_vec_1_50_with_cap ... bench: 39 ns/iter (+/- 4)
test small_vec::tests::fill_small_vec_1_50_wo_cap ... bench: 35 ns/iter (+/- 4)
test small_vec::tests::fill_small_vec_32_10_with_cap ... bench: 37 ns/iter (+/- 3)
test small_vec::tests::fill_small_vec_32_10_wo_cap ... bench: 32 ns/iter (+/- 2)
test small_vec::tests::fill_small_vec_32_50_with_cap ... bench: 52 ns/iter (+/- 4)
test small_vec::tests::fill_small_vec_32_50_wo_cap ... bench: 46 ns/iter (+/- 0)
test small_vec::tests::fill_small_vec_8_10_with_cap ... bench: 35 ns/iter (+/- 4)
test small_vec::tests::fill_small_vec_8_10_wo_cap ... bench: 31 ns/iter (+/- 0)
test small_vec::tests::fill_small_vec_8_50_with_cap ... bench: 40 ns/iter (+/- 15)
test small_vec::tests::fill_small_vec_8_50_wo_cap ... bench: 36 ns/iter (+/- 2)
```
|
|
Use Vec::extend in SmallVec::extend when applicable
As calculated in #52738, `Vec::extend` is much faster than `push`ing to it in a loop. We can take advantage of this method in `SmallVec` too - at least in cases when its underlying object is an `AccumulateVec::Heap`.
~~This approach also accidentally improves the `push` loop of the `AccumulateVec::Array` variant, because it doesn't utilize `SmallVec::push` which performs `self.reserve(1)` with every iteration; this is unnecessary, because we're already reserving the whole space we will be needing by performing `self.reserve(iter.size_hint().0)` at the beginning.~~
|
|
|
|
|
|
Simplify a few functions in rustc_data_structures
- drop `try!()` where it's superfluous
- change `try!()` to `?`
- squash a `push` with `push_str`
- refactor a push loop into an iterator
|
|
|
|
Rollup of bare_trait_objects PRs
All deny attributes were moved into bootstrap so they can be disabled with a line of config.
Warnings for external tools are allowed and it's up to the tool's maintainer to keep it warnings free.
r? @Mark-Simulacrum
cc @ljedrz @kennytm
|