| Age | Commit message (Collapse) | Author | Lines |
|
|
|
|
|
|
|
Fix debug infinite loop
Fixes #41338.
|
|
|
|
These show up in rustdoc so need to be correct.
|
|
* Changed btree_map's and hash_map's Entry (etc.) docs to be consistent
* Changed VecDeque's type and module summary sentences to be consistent
with each other as well as with other summary sentences in the module
* Changed HashMap's and HashSet's summary sentences to be less redundantly
phrased and also more consistant with the other summary sentences in the
module
* Also, added an example to Bound
|
|
* Added links where possible (limited because of facading)
* Changed references to methods from `foo()` to `foo` in module docs
* Changed references to methods from `HashMap::foo` to just `foo` in
top-level docs for `HashMap` and the `default` doc for `DefaultHasher`
* Various small other fixes
|
|
This greatly improves consistency.
|
|
Since my last PR led to linker failure, I'm now taking much smaller steps.
This only fixes some doc_markdown warnings; as they are in comments only,
we shouldn't get any problems building.
|
|
|
|
|
|
|
|
|
|
Clarify docs in `VecDeque::resize`
|
|
|
|
|
|
Add Debug implementations for libcollection structs
Part of #31869.
|
|
|
|
Fixes https://github.com/rust-lang/rust/issues/38625.
|
|
This commit applies the stabilization/deprecations of the 1.16.0 release, as
tracked by the rust-lang/rust issue tracker and the final-comment-period tag.
The following APIs were stabilized:
* `VecDeque::truncate`
* `VecDeque::resize`
* `String::insert_str`
* `Duration::checked_{add,sub,div,mul}`
* `str::replacen`
* `SocketAddr::is_ipv{4,6}`
* `IpAddr::is_ipv{4,6}`
* `str::repeat`
* `Vec::dedup_by`
* `Vec::dedup_by_key`
* `Result::unwrap_or_default`
* `<*const T>::wrapping_offset`
* `<*mut T>::wrapping_offset`
* `CommandExt::creation_flags` (on Windows)
* `File::set_permissions`
* `String::split_off`
The following APIs were deprecated
* `EnumSet` - replaced with other ecosystem abstractions, long since unstable
Closes #27788
Closes #35553
Closes #35774
Closes #36436
Closes #36949
Closes #37079
Closes #37087
Closes #37516
Closes #37827
Closes #37916
Closes #37966
Closes #38080
|
|
|
|
|
|
|
|
Replace uses of `#[unsafe_destructor_blind_to_params]` with `#[may_dangle]`
CC #34761
r? @pnkfelix
|
|
Clarify behavior of `VecDeque::insert`.
Fixes https://github.com/rust-lang/rust/issues/37046.
|
|
CC #34761
|
|
Fixes https://github.com/rust-lang/rust/issues/37046.
|
|
|
|
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).
|
|
|
|
These are displayed by rustdoc so should be correct.
|
|
|
|
|
|
|
|
|
|
Implement 1581 (FusedIterator)
* [ ] Implement on patterns. See https://github.com/rust-lang/rust/issues/27721#issuecomment-239638642.
* [ ] Handle OS Iterators. A bunch of iterators (`Args`, `Env`, etc.) in libstd wrap platform specific iterators. The current ones all appear to be well-behaved but can we assume that future ones will be?
* [ ] Does someone want to audit this? On first glance, all of the iterators on which I implemented `FusedIterator` appear to be well-behaved but there are a *lot* of them so a second pair of eyes would be nice.
* I haven't touched rustc internal iterators (or the internal rand) because rustc doesn't actually call `fuse()`.
* `FusedIterator` can't be implemented on `std::io::{Bytes, Chars}`.
Closes: #35602 (Tracking Issue)
Implements: rust-lang/rfcs#1581
|
|
Stabilized
* `Cell::as_ptr`
* `RefCell::as_ptr`
* `IpAddr::is_{unspecified,loopback,multicast}`
* `Ipv6Addr::octets`
* `LinkedList::contains`
* `VecDeque::contains`
* `ExitStatusExt::from_raw` - both on Unix and Windows
* `Receiver::recv_timeout`
* `RecvTimeoutError`
* `BinaryHeap::peek_mut`
* `PeekMut`
* `iter::Product`
* `iter::Sum`
* `OccupiedEntry::remove_entry`
* `VacantEntry::into_key`
Deprecated
* `Cell::as_unsafe_cell`
* `RefCell::as_unsafe_cell`
* `OccupiedEntry::remove_pair`
Closes #27708
cc #27709
Closes #32313
Closes #32630
Closes #32713
Closes #34029
Closes #34392
Closes #34285
Closes #34529
|
|
This trait can be used to avoid the overhead of a fuse wrapper when an iterator
is already well-behaved.
Conforming to: RFC 1581
Closes: #35602
|
|
|
|
|
|
|
|
Add `contains` to `VecDeque` and `LinkedList` (+ tests)
This implements [RFC 1552](https://github.com/rust-lang/rfcs/blob/master/text/1552-contains-method-for-various-collections.md). Tracking issue: #32630
Sorry for the late response. This is my first contribution, so please tell me if anything isn't optimal!
|
|
|
|
|
|
This commit standardizes the codebase on `iter` for parameters with
IntoIterator bounds.
Previously about 40% of IntoIterator parameters were named `iterable`,
with most of the rest being named `iter`. There was a single place where
it was named `iterator`.
|
|
Just like for Vec. This should benefit both non-optimized and optimized
performance. Non-optimized since the intrinsic drop_in_place is easily
removed, and optimized because iterating the slices is more efficient
than using the VecDeque iterators.
|
|
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
|
|
Encountered while I was trying to work on #28518. Please let me know whether this is a correct move.
|