Additional *mut [T] methods by the8472 · Pull Request #95594 · rust-lang/rust (original) (raw)
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Conversation14 Commits3 Checks0 Files changed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.Learn more about bidirectional Unicode characters
[ Show hidden characters]({{ revealButtonHref }})
Split out from #94247
This adds the following methods to raw slices that already exist on regular slices
*mut [T]::is_empty*mut [T]::split_at_mut*mut [T]::split_at_mut_unchecked
These methods reduce the amount of unsafe code needed to migrate ChunksMut and related iterators
to raw slices (#94247)
r? @m-ou-se
This was referenced
Apr 2, 2022
Split out from rust-lang#94247
This adds the following methods to raw slices that already exist on regular slices
*mut [T]::is_empty*mut [T]::split_at_mut*mut [T]::split_at_unchecked
These methods reduce the amount of unsafe code needed to migrate ChunksMut and related iterators to raw slices (rust-lang#94247)
Co-authored-by:: The 8472 git@infinite-source.de
The implementations of ChunksMut::last and RChunksMut::last currently use checked indexing, but in the PR this is supporting I used get_unchecked_mut, only because it's already there. Should we also add some kind of checked indexing for raw slices?
Indexing raw slices could be useful, but I think that should go into a separate PR if we want to mirror SliceIndex. Plus we'd still need unsafe to deref or read the pointer.
Relevant to the library API team, which will review and decide on the PR/issue.
label
&mut [T] implies validity which automatically makes ptr::add ok within its bounds.
But *mut [T] does not. Since we still want the benefits of in-bounds pointer arithmetic
split_at_must must require the caller to pass valid pointers and therefore it is unsafe.
Hi, this PR has been open for a while with no activity and I think it's blocking me from fixing what I think is a soundness issue in the standard library: #94231
This is just a PR to add new methods behind features so I don't think it should be a lot of work to move this forward, but please let me know if there's something I can do to help.
📌 Commit b0ca46e has been approved by yaahc
Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
and removed S-waiting-on-review
Status: Awaiting review from the assignee but also interested parties.
labels
bors added a commit to rust-lang-ci/rust that referenced this pull request
Rollup of 6 pull requests
Successful merges:
- rust-lang#95594 (Additional
*mut [T]methods) - rust-lang#97130 (rustdoc: avoid including impl blocks with filled-in generics)
- rust-lang#97166 (Move conditions out of recover/report functions.)
- rust-lang#97605 (Mention filename in suggestion when it differs from primary span)
- rust-lang#97613 (rustdoc: Improve calculation of "Impls on Foreign Types")
- rust-lang#97626 (rename PointerAddress → PointerExposeAddress)
Failed merges:
r? @ghost
@rustbot modify labels: rollup
Labels
Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Relevant to the library API team, which will review and decide on the PR/issue.