diff options
| author | bors <bors@rust-lang.org> | 2023-06-13 03:23:12 +0000 |
|---|---|---|
| committer | bors <bors@rust-lang.org> | 2023-06-13 03:23:12 +0000 |
| commit | de1ff0a8b559c300fb8145123accdfa8bda1031e (patch) | |
| tree | b7b1d05aaf6b1498865821611b7ed73b2f33781f /compiler/rustc_mir_transform/src/errors.rs | |
| parent | 5e8c53f1f660236bd88bfe40145646104f265846 (diff) | |
| parent | e0e355dd253b46380f975acd33b43302ac470236 (diff) | |
| download | rust-de1ff0a8b559c300fb8145123accdfa8bda1031e.tar.gz rust-de1ff0a8b559c300fb8145123accdfa8bda1031e.zip | |
Auto merge of #99339 - yanchith:binary-heap-ta, r=Amanieu
Make BinaryHeap parametric over Allocator
Tracking issue: #32838
Related: https://github.com/rust-lang/wg-allocators/issues/7
This parametrizes `BinaryHeap` with `A`, similarly to how other collections are parametrized.
A couple things I left out:
```
BinaryHeap::append
Currently requires both structures to have the same allocator type. Could
change, but depends on Vec::append, which has the same constraints.
impl<T: Ord> Default for BinaryHeap<T>
Not parametrized, because there's nowhere to conjure the allocator from.
impl<T: Ord> FromIterator<T> for BinaryHeap<T>
Not parametrized, because there's nowhere to conjure the allocator from.
impl<T: Ord, const N: usize> From<[T; N]> for BinaryHeap<T>
Not parametrized, because there's nowhere to conjure the allocator from.
unsafe impl<I> AsVecIntoIter for IntoIter<I>
AsVecIntoIter is not allocator aware, and I didn't dare change it without guidance. Is this something important?
```
I've seen very few tests for allocator_api in general, but I'd like to at least test this on some usage code in my projects before moving forward.
EDIT: Updated the list of impls and functions that are not affected by this. `BinaryHeap` no longer has a `SpecExtend` impl, and prior work made implementing `Extend` possible.
Diffstat (limited to 'compiler/rustc_mir_transform/src/errors.rs')
0 files changed, 0 insertions, 0 deletions
