-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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 and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Tracking Issue for slice_from_ptr_range
#89792
Comments
Is there anything about provenance that should be documented on these? Right now I think it always uses the provenance of the first pointer for what it puts in the slice; I'm not sure whether it would ever matter. |
…r=oli-obk Make `from{,_mut}_ptr_range` const This PR makes the following APIs `const`: ```rust // core::slice pub const unsafe fn from_ptr_range<'a, T>(range: Range<*const T>) -> &'a [T]; pub const unsafe fn from_mut_ptr_range<'a, T>(range: Range<*mut T>) -> &'a mut [T]; ``` Tracking issue: rust-lang#89792. Feature for `from_ptr_range` as a `const fn`: `slice_from_ptr_range_const`. Feature for `from_mut_ptr_range` as a `const fn`: `slice_from_mut_ptr_range_const`. r? `@oli-obk`
@scottmcm current implementation uses
Which I think implies that both pointers must have the same provenance. The current documentation of
|
…r=oli-obk Make `from{,_mut}_ptr_range` const This PR makes the following APIs `const`: ```rust // core::slice pub const unsafe fn from_ptr_range<'a, T>(range: Range<*const T>) -> &'a [T]; pub const unsafe fn from_mut_ptr_range<'a, T>(range: Range<*mut T>) -> &'a mut [T]; ``` Tracking issue: rust-lang#89792. Feature for `from_ptr_range` as a `const fn`: `slice_from_ptr_range_const`. Feature for `from_mut_ptr_range` as a `const fn`: `slice_from_mut_ptr_range_const`. r? `@oli-obk`
…oli-obk Make `from{,_mut}_ptr_range` const This PR makes the following APIs `const`: ```rust // core::slice pub const unsafe fn from_ptr_range<'a, T>(range: Range<*const T>) -> &'a [T]; pub const unsafe fn from_mut_ptr_range<'a, T>(range: Range<*mut T>) -> &'a mut [T]; ``` Tracking issue: rust-lang#89792. Feature for `from_ptr_range` as a `const fn`: `slice_from_ptr_range_const`. Feature for `from_mut_ptr_range` as a `const fn`: `slice_from_mut_ptr_range_const`. r? `@oli-obk`
Can someone add #97419 to the implementation history? It made the functions |
What's the behavior of these functions when |
…lfJung Clarify language around ptrs in slice::raw More specifically we explicitly mention that the pointer should be non-null as a top level requirement. Nullptrs are always valid for zero sized operations, so just validity (and alignment) does not guarantee non-nullness as implied in the existing docs. We also explicitly call out ZSTs as an additional example where perhaps unintuitively alignment and non-nullness still have to hold. Finally we change `data` in the range functions to `start`, which seems like a typo to me. Touches docs for rust-lang#89792 r? RalfJung
…lfJung Clarify language around ptrs in slice::raw More specifically we explicitly mention that the pointer should be non-null as a top level requirement. Nullptrs are always valid for zero sized operations, so just validity (and alignment) does not guarantee non-nullness as implied in the existing docs. We also explicitly call out ZSTs as an additional example where perhaps unintuitively alignment and non-nullness still have to hold. Finally we change `data` in the range functions to `start`, which seems like a typo to me. Touches docs for rust-lang#89792 r? RalfJung
Rollup merge of rust-lang#129892 - oskgo:clarify-slice-from-raw, r=RalfJung Clarify language around ptrs in slice::raw More specifically we explicitly mention that the pointer should be non-null as a top level requirement. Nullptrs are always valid for zero sized operations, so just validity (and alignment) does not guarantee non-nullness as implied in the existing docs. We also explicitly call out ZSTs as an additional example where perhaps unintuitively alignment and non-nullness still have to hold. Finally we change `data` in the range functions to `start`, which seems like a typo to me. Touches docs for rust-lang#89792 r? RalfJung
Feature gate:
#![feature(slice_from_ptr_range)]
This is a tracking issue for
slice::{from_ptr_range, from_mut_ptr_range}
, counterparts toslice::{as_ptr_range, as_mut_ptr_range}
.Public API
Steps / History
slice::{from_ptr_range, from_mut_ptr_range}
#89793from{,_mut}_ptr_range
const #97419Unresolved Questions
Range
type(s) that we might want to make in a future version or edition?The text was updated successfully, but these errors were encountered: