| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
Memory was allocated via `Box::leak` and thence intended to be tracked
and deallocated manually, but the allocator was also leaked, not
tracked, and never dropped. Now it is dropped immediately.
According to my reading of the `Allocator` trait, if a copy of the
allocator remains live, then its allocations must remain live. Since
the B-tree has a copy of the allocator that will only be dropped after
the nodes, it's safe to not store the allocator in each node (which
would be a much more intrusive change).
|
|
Although these types aren't directly constructable externally, since
they're pub, I think this omission was an oversight.
|
|
|
|
|
|
|
|
fixes 134088, though it is a shame to lose some of this wonderful detail.
|
|
|
|
Signed-off-by: Jonathan Brouwer <jonathantbrouwer@gmail.com>
|
|
- Move explanations into comments to match style
- Explain the second examples
- Make variable names match the data structure
|
|
|
|
This change was requested in the btree_extract_if tracking issue:
https://github.com/rust-lang/rust/issues/70530#issuecomment-2486566328
|
|
This also seems like a small mistake: the first main sentence is put in
the same paragraph as the other two following ones while other
equivalents all have it split. Therefore, do the same here.
Signed-off-by: Paul Mabileau <paul.mabileau@harfanglab.fr>
|
|
|
|
|
|
|
|
This behavior is worth documenting because there are other plausible
alternatives, such as panicking when a duplicate is encountered, and
it reminds the programmer to consider whether they should, for example,
coalesce duplicate keys first.
|
|
* `fn get_or_insert(&mut self, value: T) -> &T`
* `fn get_or_insert_with<Q: ?Sized, F>(&mut self, value: &Q, f: F) -> &T`
* `fn entry(&mut self, value: T) -> Entry<'_, T, A>` (+ `Entry` APIs)
|
|
They are unusual methods. The docs don't really describe the cases when
they might be useful (as opposed to just `get`), and the examples don't
demonstrate the interesting cases at all.
This commit improves the docs and the examples.
|
|
The internal `btree::Recover` trait acted as a private API between
`BTreeSet` and `BTreeMap`, but we can use `pub(_)` restrictions these
days, and some of the methods don't need special handling anymore.
* `BTreeSet::get` can use `BTreeMap::get_key_value`
* `BTreeSet::take` can use `BTreeMap::remove_entry`
* `BTreeSet::replace` does need help, but this now uses a `pub(super)`
method on `BTreeMap` instead of the trait.
* `btree::Recover` is now removed.
|
|
|
|
|
|
|
|
|
|
impl `Default` for collection iterators that don't already have it
There is a pretty strong precedent for implementing `Default` for collection iterators, and this does so for some where this implementation was missed.
I don't think this needs a separate ACP (since this precedent already exists, and these feel like they were just missed), however, it *will* need an FCP since these implementations are instantly stable.
|
|
Add missing periods on `BTreeMap` cursor `peek_next` docs
Tracking issue: https://github.com/rust-lang/rust/issues/107540
|
|
The previous commit updated `rustfmt.toml` appropriately. This commit is
the outcome of running `x fmt --all` with the new formatting options.
|
|
|
|
|
|
|
|
|
|
implementation
|
|
|
|
|
|
|
|
Signed-off-by: cui fliter <imcusg@gmail.com>
|
|
Help with common API confusion, like asking for `push` when the data structure really has `append`.
```
error[E0599]: no method named `size` found for struct `Vec<{integer}>` in the current scope
--> $DIR/rustc_confusables_std_cases.rs:17:7
|
LL | x.size();
| ^^^^
|
help: you might have meant to use `len`
|
LL | x.len();
| ~~~
help: there is a method with a similar name
|
LL | x.resize();
| ~~~~~~
```
#59450
|
|
Fix BTreeMap's Cursor::remove_{next,prev}
These would incorrectly leave `current` as `None` after a failed attempt to remove an element (due to the cursor already being at the start/end).
|
|
|
|
|
|
|
|
These would incorrectly leave `current` as `None` after a failed attempt
to remove an element (due to the cursor already being at the start/end).
|
|
|
|
Co-authored-by: Joe ST <joe@fbstj.net>
|
|
Tracking issue: #107540
Currently, a `Cursor` points to a single element in the tree, and allows
moving to the next or previous element while mutating the tree. However
this was found to be confusing and hard to use.
This PR completely refactors cursors to instead point to a gap between
two elements in the tree. This eliminates the need for a "ghost" element
that exists after the last element and before the first one.
Additionally, `upper_bound` and `lower_bound` now have a much clearer
meaning.
The ability to mutate keys is also factored out into a separate
`CursorMutKey` type which is unsafe to create. This makes the API easier
to use since it avoids duplicated versions of each method with and
without key mutation.
API summary:
```rust
impl<K, V> BTreeMap<K, V> {
fn lower_bound<Q>(&self, bound: Bound<&Q>) -> Cursor<'_, K, V>
where
K: Borrow<Q> + Ord,
Q: Ord;
fn lower_bound_mut<Q>(&mut self, bound: Bound<&Q>) -> CursorMut<'_, K, V>
where
K: Borrow<Q> + Ord,
Q: Ord;
fn upper_bound<Q>(&self, bound: Bound<&Q>) -> Cursor<'_, K, V>
where
K: Borrow<Q> + Ord,
Q: Ord;
fn upper_bound_mut<Q>(&mut self, bound: Bound<&Q>) -> CursorMut<'_, K, V>
where
K: Borrow<Q> + Ord,
Q: Ord;
}
struct Cursor<'a, K: 'a, V: 'a>;
impl<'a, K, V> Cursor<'a, K, V> {
fn next(&mut self) -> Option<(&'a K, &'a V)>;
fn prev(&mut self) -> Option<(&'a K, &'a V)>;
fn peek_next(&self) -> Option<(&'a K, &'a V)>;
fn peek_prev(&self) -> Option<(&'a K, &'a V)>;
}
struct CursorMut<'a, K: 'a, V: 'a>;
impl<'a, K, V> CursorMut<'a, K, V> {
fn next(&mut self) -> Option<(&K, &mut V)>;
fn prev(&mut self) -> Option<(&K, &mut V)>;
fn peek_next(&mut self) -> Option<(&K, &mut V)>;
fn peek_prev(&mut self) -> Option<(&K, &mut V)>;
unsafe fn insert_after_unchecked(&mut self, key: K, value: V);
unsafe fn insert_before_unchecked(&mut self, key: K, value: V);
fn insert_after(&mut self, key: K, value: V);
fn insert_before(&mut self, key: K, value: V);
fn remove_next(&mut self) -> Option<(K, V)>;
fn remove_prev(&mut self) -> Option<(K, V)>;
fn as_cursor(&self) -> Cursor<'_, K, V>;
unsafe fn with_mutable_key(self) -> CursorMutKey<'a, K, V, A>;
}
struct CursorMutKey<'a, K: 'a, V: 'a>;
impl<'a, K, V> CursorMut<'a, K, V> {
fn next(&mut self) -> Option<(&mut K, &mut V)>;
fn prev(&mut self) -> Option<(&mut K, &mut V)>;
fn peek_next(&mut self) -> Option<(&mut K, &mut V)>;
fn peek_prev(&mut self) -> Option<(&mut K, &mut V)>;
unsafe fn insert_after_unchecked(&mut self, key: K, value: V);
unsafe fn insert_before_unchecked(&mut self, key: K, value: V);
fn insert_after(&mut self, key: K, value: V);
fn insert_before(&mut self, key: K, value: V);
fn remove_next(&mut self) -> Option<(K, V)>;
fn remove_prev(&mut self) -> Option<(K, V)>;
fn as_cursor(&self) -> Cursor<'_, K, V>;
unsafe fn with_mutable_key(self) -> CursorMutKey<'a, K, V, A>;
}
```
|
|
Closes rust-lang/wg-allocators#118
|
|
Clarify behavior of inclusive bounds in BTreeMap::{lower,upper}_bound
It wasn’t quite clear to me how these methods would interpret inclusive bounds so I added examples for those.
|
|
Not useful, for there is just a single example
|
|
|
