| Age | Commit message (Collapse) | Author | Lines |
|
Preparation for allocator aware `Box`
This cleans up the `Box` code a bit, and uses `Box::from_raw(ptr)` instead of `Box(ptr)`.
Additionally, `box_free` and `exchange_malloc` now uses the `AllocRef` trait and a comment was added on how `box_free` is tied to `Box`.
This a preparation for an upcoming PR, which makes `Box` aware of an allocator.
r? @Amanieu
|
|
|
|
|
|
implement AsMut<str> for String
Closes #68741.
|
|
Derive Clone + Eq for std::string::FromUtf8Error
Implement `Clone` and `Eq` for `std::string::FromUtf8Error`.
Both the inner `Vec<u8>` and `std::str::Utf8Error` are also `Clone + Eq`, so I don't see why we shouldn't derive them on `FromUtf8Error` as well.
(impl are insta-stable, requiring FCP from T-libs.)
|
|
Fix and test implementation of BTreeMap's first/last_entry, pop_first/last
Properly implement and test `first_entry` & `last_entry` to fix problem report #68829
|
|
BtreeMap range_search spruced up
#39457 created a lower level entry point for `range_search` to operate on, but it's really not hard to move it up a level of abstraction, making it somewhat shorter and reusing existing unsafe code (`new_edge` is unsafe although it is currently not tagged as such).
Benchmark added. Comparison says there's no real difference:
```
>cargo benchcmp old3.txt new3.txt --threshold 5
name old3.txt ns/iter new3.txt ns/iter diff ns/iter diff % speedup
btree::map::find_seq_100 19 21 2 10.53% x 0.90
btree::map::range_excluded_unbounded 3,117 2,838 -279 -8.95% x 1.10
btree::map::range_included_unbounded 1,768 1,871 103 5.83% x 0.94
btree::set::intersection_10k_neg_vs_10k_pos 35 37 2 5.71% x 0.95
btree::set::intersection_staggered_100_vs_10k 2,488 2,314 -174 -6.99% x 1.08
btree::set::is_subset_10k_vs_100 3 2 -1 -33.33% x 1.50
```
r? @Mark-Simulacrum
|
|
|
|
|
|
Generator Resume Arguments
cc https://github.com/rust-lang/rust/issues/43122 and https://github.com/rust-lang/rust/issues/56974
Blockers:
* [x] Fix miscompilation when resume argument is live across a yield point (https://github.com/rust-lang/rust/pull/68524#issuecomment-578459069)
* [x] Fix 10% compile time regression in `await-call-tree` benchmarks (https://github.com/rust-lang/rust/pull/68524#issuecomment-578487162)
* [x] Fix remaining 1-3% regression (https://github.com/rust-lang/rust/pull/68524#issuecomment-579566255) - resolved (https://github.com/rust-lang/rust/pull/68524#issuecomment-581144901)
* [x] Make dropck rules account for resume arguments (https://github.com/rust-lang/rust/pull/68524#issuecomment-578541137)
Follow-up work:
* Change async/await desugaring to make use of this feature
* Rewrite [`box_region.rs`](https://github.com/rust-lang/rust/blob/3d8778d767f0dde6fe2bc9459f21ead8e124d8cb/src/librustc_data_structures/box_region.rs) to use resume arguments (this shows up in profiles too)
|
|
pop_first, pop_last
|
|
Added upper bound of what vecs and boxes can allocate
Fixed issue #68593
I added a line of documentation to these two files to reflect that vectors and boxes ensure that they never allocate more than `isize::MAX` bytes.
r? @steveklabnik
|
|
|
|
|
|
|
|
|
|
|
|
Add `#![doc(html_playground_url = ...)]` to alloc crate
This adds the Run button to code examples just like the core and std docs have.
|
|
This adds the Run button to code examples just like the core and std docs have.
|
|
BTreeMap: tag and explain unsafe internal functions or assert preconditions
#68418 concluded that it's not desirable to tag all internal functions with preconditions as being unsafe. This PR does it to some functions, documents why, and elsewhere enforces the preconditions with asserts.
|
|
Implement clone_from for BTreeMap and BTreeSet
See #28481. This results in up to 90% speedups on simple data types when `self` and `other` are the same size, and is generally comparable or faster. Some concerns:
1. This implementation requires an `Ord` bound on the `Clone` implementation for `BTreeMap` and `BTreeSet`. Since these structs can only be created externally for keys with `Ord` implemented, this should be fine? If not, there's certainly a less safe way to do this.
2. Changing `next_unchecked` on `RangeMut` to return mutable key references allows for replacing the entire overlapping portion of both maps without changing the external interface in any way. However, if `clone_from` fails it can leave the `BTreeMap` in an invalid state, which might be unacceptable.
~This probably needs an FCP since it changes a trait bound, but (as far as I know?) that change cannot break any external code.~
|
|
Co-Authored-By: Mark Rousskov <mark.simulacrum@gmail.com>
|
|
fix: typo in vec.rs
|
|
Add BTreeMap::remove_entry
Implements https://github.com/rust-lang/rust/issues/66714.
|
|
|
|
|
|
|
|
Co-Authored-By: Ashley Mannix <ashleymannix@live.com.au>
|
|
Rename `Alloc` to `AllocRef`
The allocator-wg has decided to merge this change upstream in https://github.com/rust-lang/wg-allocators/issues/8#issuecomment-577122958.
This renames `Alloc` to `AllocRef` because types that implement `Alloc` are a reference, smart pointer, or ZSTs. It is not possible to have an allocator like `MyAlloc([u8; N])`, that owns the memory and also implements `Alloc`, since that would mean, that moving a `Vec<T, MyAlloc>` would need to correct the internal pointer, which is not possible as we don't have move constructors.
For further explanation please see https://github.com/rust-lang/wg-allocators/issues/8#issuecomment-489464843 and the comments after that one.
Additionally it clarifies the semantics of `Clone` on an allocator. In the case of `AllocRef`, it is clear that the cloned handle still points to the same allocator instance, and that you can free data allocated from one handle with another handle.
The initial proposal was to rename `Alloc` to `AllocHandle`, but `Ref` expresses the semantics better than `Handle`. Also, the only appearance of `Handle` in `std` are for windows specific resources, which might be confusing.
Blocked on https://github.com/rust-lang/miri/pull/1160
|
|
|
|
Mainly for API parity with HashMap.
- Add BTreeMap::remove_entry
- Rewrite BTreeMap::remove to use remove_entry
- Use btreemap_remove_entry feature in doc comment
|
|
Stabilize ptr::slice_from_raw_parts[_mut]
Closes #36925, the tracking issue.
Initial impl: #60667
r? @rust-lang/libs
In addition to stabilizing, I've adjusted the example of `ptr::slice_from_raw_parts` to use `slice_from_raw_parts` instead of `slice_from_raw_parts_mut`, which was unnecessary for the example as written.
|
|
|
|
Simplify NodeHeader by avoiding slices in BTreeMaps with shared roots
Simplify a complicated piece of code that creates slices of keys in node leaves.
|
|
|
|
|
|
Add more BTreeMap/BTreeSet benchmarks regarding iteration
Serving #67073 or other developments
|
|
More thorough testing of BTreeMap::range
Test more of the paths in the `range_search` function in map.rs
|
|
|
|
Use pointer offset instead of deref for A/Rc::into_raw
Internals thread: https://internals.rust-lang.org/t/rc-and-internal-mutability/11463/2?u=cad97
The current implementation of (`A`)`Rc::into_raw` uses the `Deref::deref` implementation to get the pointer-to-data that is returned. This is problematic in the proposed Stacked Borrow rules, as this only gets shared provenance over the data location. (Note that the strong/weak counts are `UnsafeCell` (`Cell`/`Atomic`) so shared provenance can still mutate them, but the data itself is not.) When promoted back to a real reference counted pointer, the restored pointer can be used for mutation through `::get_mut` (if it is the only surviving reference). However, this mutates through a pointer ultimately derived from a `&T` borrow, violating the Stacked Borrow rules.
There are three known potential solutions to this issue:
- Stacked Borrows is wrong, liballoc is correct.
- Fully admit (`A`)`Rc` as an "internal mutability" type and store the data payload in an `UnsafeCell` like the strong/weak counts are. (Note: this is not needed generally since the `RcBox`/`ArcInner` is stored behind a shared `NonNull` which maintains shared write provenance as a raw pointer.)
- Adjust `into_raw` to do direct manipulation of the pointer (like `from_raw`) so that it maintains write provenance and doesn't derive the pointer from a reference.
This PR implements the third option, as recommended by @RalfJung.
Potential future work: provide `as_raw` and `clone_raw` associated functions to allow the [`&T` -> (`A`)`Rc<T>` pattern](https://internals.rust-lang.org/t/rc-and-internal-mutability/11463/2?u=cad97) to be used soundly without creating (`A`)`Rc` from references.
|
|
Implement Cursor for linked lists. (RFC 2570).
cc. #58533 cc. @Gankra
r? @Amanieu
|
|
|
|
|
|
|
|
|
|
|
|
|
|
r=alexcrichton"
This reverts commit 4ed415b5478c74094c2859abfddb959588cd6bb1, reversing
changes made to 3cce950743e8aa74a4378dfdefbbc80223a00865.
|
|
|
|
Co-Authored-By: Ralf Jung <post@ralfj.de>
|