| Age | Commit message (Collapse) | Author | Lines |
|
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>
|
|
|
|
Simplify Clone for Box<[T]>
The bespoke `BoxBuilder` was basically a very simple `Vec`. Instead,
let's clone to a real `Vec`, with all of its specialization for the
task, then convert back to `Box<[T]>`.
|
|
Formatting an example for method Vec.retain
|
|
|
|
|
|
|
|
|
|
change remove to have a PartialEq bound
Addresses [comment](https://github.com/rust-lang/rust/pull/67727#issuecomment-570660301).
References #40062
r? @Amanieu
|
|
|
|
|
|
|
|
Tweak and extend internal BTreeMap documentation, including debug asserts.
Gathered from work on various other pull requests (e.g. #67725, #67686).
|
|
|
|
|
|
Co-Authored-By: Robin Kruppe <robin.kruppe@gmail.com>
|
|
|
|
|
|
prune ill-conceived BTreeMap iter_mut assertion and test its mutability
Proposal to deal with #67438 (and I'm more sure now that this is the right thing to do).
Passes testing with miri.
|
|
Remove redundant link texts
Most of these links are followed by a parenthesized expression. I think that the redundant link texts were added to prevent interpretation as an inline link. This is unnecessary since the closing square bracket and opening parenthesis are separated by whitespace.
|
|
|
|
|
|
|
|
The bespoke `BoxBuilder` was basically a very simple `Vec`. Instead,
let's clone to a real `Vec`, with all of its specialization for the
task, then convert back to `Box<[T]>`.
|
|
|
|
Warn against relying on ?Sized being last
Fixes #62522
|
|
|
|
|
|
Remove a const-if-hack in RawVec
r? @ecstatic-morse
cc @Centril
|
|
add string.insert benchmarks
This adds benchmarks for `String::insert` and `String::insert_str`
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Stabilize `std::{rc,sync}::Weak::{weak_count, strong_count}`
* Original PR: #56696
* Tracking issue: #57977
Closes: #57977
Supporting comments:
> Although these were added for testing, it is occasionally useful to have a way to probe optimistically for whether a weak pointer has become dangling, without actually taking the overhead of manipulating atomics. Are there any plans to stabilize this?
_Originally posted by @bdonlan in https://github.com/rust-lang/rust/issues/57977#issuecomment-516970921_
> Having this stabilized would help. Currently, the only way to check if a weak pointer has become dangling is to call `upgrade`, which is by far expensive.
_Originally posted by @glebpom in https://github.com/rust-lang/rust/issues/57977#issuecomment-526934709_
Not sure if stabilizing these warrants a full RFC, so throwing this out here as a start for now.
Note: per CONTRIBUTING.md, I ran the tidy checks, but they seem to be failing on unchanged files (primarily in `src/stdsimd`).
|
|
|