| Age | Commit message (Collapse) | Author | Lines |
|
Implement ordered/sorted iterators on BinaryHeap as per #59278
I've implemented the ordered version of iterator on BinaryHeap as per #59278.
# Added methods:
* `.into_iter_sorted()`
* like `.into_iter()`; but returns elements in heap order
* `.drain_sorted()`
* like `.drain()`; but returns elements in heap order
* It's a bit _lazy_; elements are removed on drop. (Edit: it’s similar to vec::Drain)
For `DrainSorted` struct, I implemented `Drop` trait following @scottmcm 's [suggestion](https://github.com/rust-lang/rust/issues/59278#issuecomment-537306925)
# ~TODO~ DONE
* ~I think I need to add more tests other than doctest.~
# **Notes:**
* we renamed `_ordered` to `_sorted`, because the latter is more common in rust libs. (as suggested by @KodrAus )
|
|
Stabilize `Option::flatten`
- PR: https://github.com/rust-lang/rust/pull/60256
- Tracking issue: https://github.com/rust-lang/rust/issues/60258
@elahn
> I was trying to `flat_map()` and found `map().flatten()` does the trick. This has been on nightly for 4 months, can we stabilise it?
@ethanboxx
> @Centril Helped me get this merged. What is the stabilization process?
@Centril
> @ethanboxx I'd just file a PR to stabilize it and we'll ask T-libs to FCP.
So here I am.
I am was unsure what number to put in `since = "-"` so I copied what someone had done in a recent PR.
|
|
|
|
* `.drain_sorted()` doc change suggested by @KodrAus
|
|
BTreeSet symmetric_difference & union optimized
No scalability changes, but:
- Grew the cmp_opt function (shared by symmetric_difference & union) into a MergeIter, with less memory overhead than the pairs of Peekable iterators now, speeding up ~20% on my machine (not so clear on Travis though, I actually switched it off there because it wasn't consistent about identical code). Mainly meant to improve readability by sharing code, though it does end up using more lines of code. Extending and reusing the MergeIter in btree_map might be better, but I'm not sure that's possible or desirable. This MergeIter probably pretends to be more generic than it is, yet doesn't declare to be an iterator because there's no need to, it's only there to help construct genuine iterators SymmetricDifference & Union.
- Compact the code of #64820 by moving if/else into match guards.
r? @bluss
|
|
|
|
Fix zero-size uninitialized boxes
Requesting a zero-size allocation is not allowed, return a dangling pointer instead.
CC https://github.com/rust-lang/rust/issues/63291#issuecomment-538692745
|
|
|
|
|
|
- Compatible with Emscripten 1.38.46-upstream or later upstream.
- Refactors the Emscripten target spec to share code with other wasm
targets.
- Replaces the old incorrect wasm32 C call ABI with the correct one,
preserving the old one as wasm32_bindgen_compat for wasm-bindgen
compatibility.
- Updates the varargs ABI used by Emscripten and deletes the old one.
- Removes the obsolete wasm32-experimental-emscripten target.
- Uses EMCC_CFLAGS on CI to avoid the timeout problems with #63649.
|
|
r=alexcrichton"
This reverts commit 7870050796e5904a0fc85ecbe6fa6dde1cfe0c91, reversing
changes made to 2e7244807a7878f6eca3eb7d97ae9b413aa49014.
|
|
|
|
|
|
|
|
https://github.com/rust-lang/rust/pull/49496 introduced specialization based on:
```
unsafe impl<T: ?Sized> IsZero for *mut T {
fn is_zero(&self) -> bool {
(*self).is_null()
}
}
```
… to call `RawVec::with_capacity_zeroed` for creating `Vec<*mut T>`,
which is incorrect for fat pointers
since `<*mut T>::is_null` only looks at the data component.
That is, a fat pointer can be “null” without being made entirely of zero bits.
This commit fixes it by removing the `?Sized` bound on this impl
(and the corresponding `*const T` one).
This regresses `vec![x; n]` with `x` a null raw slice of length zero,
but that seems exceptionally uncommon.
(Vtable pointers are never null, so raw trait objects would not take
the fast path anyway.
An alternative to keep the `?Sized` bound
(or even generalize to `impl<U: Copy> IsZero for U`)
would be to cast to `&[u8]` of length `size_of::<U>()`,
but the optimizer seems not to be able to propagate alignment information
and sticks with comparing one byte at a time:
https://rust.godbolt.org/z/xQFkwL
----
Without the library change, the new test fails as follows:
```
---- vec::vec_macro_repeating_null_raw_fat_pointer stdout ----
[src/liballoc/tests/vec.rs:1301] ptr_metadata(raw_dyn) = 0x00005596ef95f9a8
[src/liballoc/tests/vec.rs:1306] ptr_metadata(vec[0]) = 0x0000000000000000
thread 'vec::vec_macro_repeating_null_raw_fat_pointer' panicked at 'assertion failed: vec[0] == null_raw_dyn', src/liballoc/tests/vec.rs:1307:5
```
|
|
The commented invariant that an iterator is smaller than other iterator
was violated after next is called and two iterators are consumed at
different rates.
|
|
… and add a separately-unstable field to force non-exhaustive matching
(`#[non_exhaustive]` is no implemented yet on enum variants)
so that we have the option to later expose the allocator’s error value.
CC https://github.com/rust-lang/wg-allocators/issues/23
|
|
|
|
Use associated_type_bounds where applicable - closes #61738
|
|
reduce some test sizes in Miri
|
|
|
|
|
|
Merge recent changes into master
|
|
|
|
|
|
|
|
|
|
|
|
rustbuild
Remove some random unnecessary lint `allow`s
|
|
Add `impl<T> FromIterator<T> for Arc/Rc<[T]>`
Add implementations of `FromIterator<T> for Arc/Rc<[T]>` with symmetrical logic.
This also takes advantage of specialization in the case of iterators with known length (`TrustedLen`) to elide the final allocation/copying from a `Vec<T>` into `Rc<[T]>` because we can allocate the space for the `Rc<[T]>` directly when the size is known. This is the primary motivation and why this is to be preferred over `iter.collect::<Vec<_>>().into(): Rc<[T]>`.
Moreover, this PR does some refactoring in some places.
r? @RalfJung for the code
cc @alexcrichton from T-libs
|
|
Prevent Vec::drain_filter from double dropping on panic
Fixes: #60977
The changes in this PR prevent leaking and double-panicking in addition to double-drop.
Tracking issue: #43244
|
|
request at least ptr-size alignment from posix_memalign
Fixes https://github.com/rust-lang/rust/issues/62251
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Fixes: #60977
|
|
|
|
|
|
Use iter() for iterating arrays by slice
These `into_iter()` calls will change from iterating references to
values if we ever get `IntoIterator` for arrays, which may break the
code using that iterator. Calling `iter()` is future proof.
|
|
These `into_iter()` calls will change from iterating references to
values if we ever get `IntoIterator` for arrays, which may break the
code using that iterator. Calling `iter()` is future proof.
|
|
|
|
|
|
|
|
|
|
|
|
Improved test output
|
|
|