| Age | Commit message (Collapse) | Author | Lines |
|---|
|
This change moves:
1. `libcoretest` into `libcore/tests`
2. `libcollectionstest` into `libcollections/tests`
This is a follow-up to #39561.
|
|
|
|
And libcore/benches
|
|
Fixes https://github.com/rust-lang/rust/issues/38625.
|
|
Improve is_empty on the VecDeque and its iterators by just comparing
tail and head; this saves a few instructions (to be able to remove the
`& (size - 1)` computation, it would have to know that size is a power of two).
|
|
run rustfmt on libcollectionstest
|
|
|
|
|
|
|
|
|
|
|
|
Right now everything in TARGET_CRATES is built by default for all non-fulldeps
tests and is distributed by default for all target standard library packages.
Currenly this includes a number of unstable crates which are rarely used such as
`graphviz` and `rbml`>
This commit trims down the set of `TARGET_CRATES`, moves a number of tests to
`*-fulldeps` as a result, and trims down the dependencies of libtest so we can
distribute fewer crates in the `rust-std` packages.
|
|
This improves == for VecDeque by using the slice representation.
This will also improve further if codegen for slice comparison improves.
Benchmark run of 1000 u64 elements, comparing for equality (all equal).
Cpu time to compare the vecdeques is reduced to less than 50% of what it
was before.
```
test test_eq_u64 ... bench: 1,885 ns/iter (+/- 163) = 4244 MB/s
test test_eq_new_u64 ... bench: 802 ns/iter (+/- 100) = 9975 MB/s
```
|
|
Use .as_slices() for a more efficient code path in VecDeque's Hash impl.
This still hashes the elements in the same order.
Before/after timing of VecDeque hashing 1024 elements of u8 and
u64 shows that the vecdeque now can match the Vec
(test_hashing_vec_of_u64 is the Vec run).
before
test test_hashing_u64 ... bench: 14,031 ns/iter (+/- 236) = 583 MB/s
test test_hashing_u8 ... bench: 7,887 ns/iter (+/- 65) = 129 MB/s
test test_hashing_vec_of_u64 ... bench: 6,578 ns/iter (+/- 76) = 1245 MB/s
after
running 5 tests
test test_hashing_u64 ... bench: 6,495 ns/iter (+/- 52) = 1261 MB/s
test test_hashing_u8 ... bench: 851 ns/iter (+/- 16) = 1203 MB/s
test test_hashing_vec_of_u64 ... bench: 6,499 ns/iter (+/- 59) = 1260 MB/s
|
|
|
|
This commit removes all unstable and deprecated functions in the standard
library. A release was recently cut (1.3) which makes this a good time for some
spring cleaning of the deprecated functions.
|
|
|
|
Closes #25976.
|
|
|
|
This is a deprecated attribute that is slated for removal, and it also affects
all implementors of the trait. This commit removes the attribute and fixes up
implementors accordingly. The primary implementation which was lost was the
ability to compare `&[T]` and `Vec<T>` (in that order).
This change also modifies the `assert_eq!` macro to not consider both directions
of equality, only the one given in the left/right forms to the macro. This
modification is motivated due to the fact that `&[T] == Vec<T>` no longer
compiles, causing hundreds of errors in unit tests in the standard library (and
likely throughout the community as well).
Closes #19470
[breaking-change]
|
|
This commit cleans out a large amount of deprecated APIs from the standard
library and some of the facade crates as well, updating all users in the
compiler and in tests as it goes along.
|
|
This is a deprecated attribute that is slated for removal, and it also affects
all implementors of the trait. This commit removes the attribute and fixes up
implementors accordingly. The primary implementation which was lost was the
ability to compare `&[T]` and `Vec<T>` (in that order).
This change also modifies the `assert_eq!` macro to not consider both directions
of equality, only the one given in the left/right forms to the macro. This
modification is motivated due to the fact that `&[T] == Vec<T>` no longer
compiles, causing hundreds of errors in unit tests in the standard library (and
likely throughout the community as well).
cc #19470
[breaking-change]
|
|
This commit stabilizes the `cloned` iterator after tweaking the signature to
require that the iterator is over `&T` instead of `U: Deref<T>`. This method has
had time to bake for awhile now and it's not clear whether the `Deref` bound is
worth it. Additionally, there aren't clear conventions on when to bound and/or
implement the `Deref` trait, so for now the conservative route is to require
references instead of `U: Deref<T>`.
To change this signature to using `Deref` would technically be a
backwards-incompatible change, but it is doubtful that any code will actually
break in practice.
|
|
|
|
|
