rust/library/alloc/src/collections/btree, branch masterhttps://github.com/rust-lang/rust
http://git.dreamy.place/mirrors/rust/atom?h=master2025-09-29T05:08:05+00:00Use `Iterator::eq` and (dogfood) `eq_by` in compiler and library2025-09-29T05:08:05+00:00Yotam Ofekyotam.ofek@gmail.com2025-09-27T17:57:50+00:00urn:sha1:68a7c250788833305f73f816b284aafa9e62370aUpdate CURRENT_RUSTC_VERSION post-bump2025-09-26T22:41:32+00:00Mark Rousskovmark.simulacrum@gmail.com2025-09-14T14:30:29+00:00urn:sha1:4e9716fbc5fb0f85d838ee9350ade2be5c2a6201Rollup merge of #146859 - cammeresi:btree-alloc-20250920, r=joboet2025-09-25T16:15:09+00:00Matthias Krüger476013+matthiaskrgr@users.noreply.github.com2025-09-25T16:15:09+00:00urn:sha1:83cf8f98600a18c690ce890bd7c0f25c14351815
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
BTreeMap: Don't leak allocators when initializing nodes2025-09-25T01:08:32+00:00Sidney Cammeresisac@cheesecake.org2025-09-20T23:54:51+00:00urn:sha1:137d4eaf12139af894da6c0b6fe74195d6b7b98c
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).
btree InternalNode::new safety comments2025-09-21T12:05:09+00:00Marijn Schoutenmhkbst@gmail.com2025-09-21T12:05:09+00:00urn:sha1:2dfcd0948e0dc1608a04e35d2f1812a21cf45b7aAdd unstable attribute to BTreeMap-related allocator generics2025-09-20T04:32:15+00:00Sidney Cammeresisac@cheesecake.org2025-09-20T04:17:21+00:00urn:sha1:42b38e3781ee3c34cf3df4dea4cd836a814cfb60
Although these types aren't directly constructable externally, since
they're pub, I think this omission was an oversight.
btree: safety comments for init and new2025-09-19T17:21:55+00:00Marijn Schoutenmhkbst@gmail.com2025-09-19T17:21:55+00:00urn:sha1:e2de670558111dc6ce46d764aed6cb3dc4222794Rollup merge of #144871 - Kivooeo:btree_entry_insert-stabilize, r=jhpratt2025-09-17T04:56:42+00:00Stuart CookZalathar@users.noreply.github.com2025-09-17T04:56:42+00:00urn:sha1:feeb68eb5e6a09053a499461b3e7ce471447ebf6
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_if2025-08-27T18:34:31+00:00Sidney Cammeresisac@readyset.io2025-08-15T15:45:50+00:00urn:sha1:f8a7f82bdab57302ca07ea5f3b3fa5173ed9f9aeRollup merge of #144373 - hkBst:remove-deprecated-1, r=jhpratt2025-08-26T14:34:09+00:00Guillaume Gomezguillaume1.gomez@gmail.com2025-08-26T14:34:09+00:00urn:sha1:9bb7d17d9a303a12c98ac569c96902084ee3d792
remove deprecated Error::description in impls
[libs-api permission](https://github.com/rust-lang/libs-team/issues/615#issuecomment-3074045829)
r? `@cuviper`
or `@jhpratt`