| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
Remove most `#[track_caller]` from allocating Vec methods
They cause significant binary size overhead while contributing little value.
closes rust-lang/rust#146963, see that issue for more details.
|
|
|
|
They cause significant binary size overhead while contributing little
value.
Also removes them from the wrapping String methods that do not panic.
|
|
BTreeMap: Don't leak allocators when initializing nodes
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).
Fixes: rust-lang/rust#106203
|
|
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).
|
|
|
|
Add unstable attribute to BTreeMap-related allocator generics
Although these types aren't directly constructable externally, since they're pub, I think this omission was an oversight.
r? libs-api
|
|
|
|
Although these types aren't directly constructable externally, since
they're pub, I think this omission was an oversight.
|
|
|
|
Stabilize `btree_entry_insert` feature
This stabilises `btree_map::VacantEntry::insert_entry` and `btree_map::Entry::insert_entry`, following the FCP in [tracking issue](https://github.com/rust-lang/rust/issues/65225).
New stable API:
```rust
impl<'a, K: Ord, V, A: Allocator + Clone> Entry<'a, K, V, A> {
pub fn insert_entry(self, value: V) -> OccupiedEntry<'a, K, V, A>;
}
impl<'a, K: Ord, V, A: Allocator + Clone> VacantEntry<'a, K, V, A> {
pub fn insert_entry(mut self, value: V) -> OccupiedEntry<'a, K, V, A>;
}
```
(FCP ended almost a year ago, so if it's needed for process we could rerun it)
Closes: https://github.com/rust-lang/rust/issues/65225
|
|
Stabilize BTree{Map,Set}::extract_if
Tracking issue: rust-lang/rust#70530
FCP completed: https://github.com/rust-lang/rust/issues/70530#issuecomment-3191454465
Closes: rust-lang/rust#70530
|
|
|
|
|
|
remove deprecated Error::description in impls
[libs-api permission](https://github.com/rust-lang/libs-team/issues/615#issuecomment-3074045829)
r? `@cuviper`
or `@jhpratt`
|
|
|
|
|
|
|
|
fixes 134088, though it is a shame to lose some of this wonderful detail.
|
|
|
|
Signed-off-by: Jonathan Brouwer <jonathantbrouwer@gmail.com>
|
|
|
|
|
|
|
|
|
|
The method `BTreeSet::from_sorted_iter` was introduced in 49ccb7519f55bd117d2ab50b7a030637f380aec6,
but it was not consistently used throughout the codebase. As a result, some code redundantly reimplemented its logic.
This commit fixes the problem.
|
|
|
|
alloc: less static mut + some cleanup
I'm looking into https://github.com/rust-lang/rust/issues/125035 and would like some feedback on my approach.
|
|
|
|
|
|
|
|
- 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
|
|
Docs(lib): Fix `extract_if` docs
Various fixes to the documentation comments of the several `extract_if` collection methods available. It originally started with a small typo fix in `Vec`'s spotted when reading the 1.87 release notes, but then by looking at the others' for comparison in order to try determining what was the intended sentence, some inconsistencies were spotted. Therefore, some other changes are also proposed here to reduce these avoidable differences, going more and more nit-picky along the way. See the individual commits for more details about each change.
`@rustbot` label T-libs A-collections A-docs
|
|
Signed-off-by: xizheyin <xizheyin@smail.nju.edu.cn>
|
|
Signed-off-by: Paul Mabileau <paul.mabileau@harfanglab.fr>
|
|
Take the one from `BTreeMap` that seems the best-worded and most
precise among the available variations.
Signed-off-by: Paul Mabileau <paul.mabileau@harfanglab.fr>
|
|
Also fixes `HashSet`'s that incorrectly designated itself as a `list`.
Signed-off-by: Paul Mabileau <paul.mabileau@harfanglab.fr>
|
|
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>
|
|
Implement `VecDeque::truncate_front()`
Tracking issue: #140667
|
|
|
|
Tracking issue: #140667
Signed-off-by: Vladimir Krivopalov <vladimir.krivopalov@gmail.com>
|
|
I found these by grepping for `&[a-z_\.]*\.clone()`, i.e. expressions
like `&a.b.clone()`, which are sometimes unnecessary clones, and also
looking at clones nearby to cases like that.
|
|
|
|
|
|
Add PeekMut::refresh
I'm not sure if this should go through ACP or not. BinaryHeap is not the most critical data structure in the standard library and it would be understandable if maintainer throughput is thus too limited to accept this PR without a proper design phase that ensures the required understanding of consequence over a longer time period.
This aims to improve the useability of heaps for priority-based work queues. In certain scenarios, modifications on the most relevant or critical items are performed until a condition that determines the work items have been sufficiently addressed. For instance the criticality could be a deadline that is relaxed whenever some part of a work item is completed. Such a loop will repeatedly access the most critical item and put it back in a sorted position when it is complete. Crucially, due to the ordering invariant we know that all necessary work was performed when the completed item remains the most critical. Getting this information from the heap position avoids a (potentially more costly) check on the item state itself.
A customized `drop` with boolean result would avoid up to two more comparisons performed in both the last no-op refresh and Drop code but this occurs once in each execution of the above scenario whereas refresh occurs any number of times. Also note that the comparison overhead of Drop is only taken if the element is mutably inspected to determine the end condition, i.e. not when refresh itself is the break condition.
|
