-
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
Stabilize const versions of ptr::slice_from_raw_parts and slice::from_raw_parts. #94946
Stabilize const versions of ptr::slice_from_raw_parts and slice::from_raw_parts. #94946
Conversation
Some changes occured to rustc_codegen_cranelift cc @bjorn3 |
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @dtolnay (or someone else) soon. Please see the contribution instructions for more information. |
@rustbot modify labels: +T-libs-api |
library/core/src/slice/raw.rs
Outdated
#[unstable(feature = "const_slice_from_raw_parts", issue = "67456")] | ||
#[rustc_const_unstable(feature = "const_slice_from_raw_parts", issue = "67456")] | ||
#[rustc_const_stable(since = "1.61.0")] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Admittedly, this is a change I'm not 100% sure on: its callers are stable in a non-const context, and yet it was marked unstable
. I have no real clue what unstable
even implies for a non-exported function, so this was mostly a no-thinking-involved mechanical change.
Looking at the CI failure, it looks like this actually unwinds a bit to depending on It's not clear to me if it can also be made const stable safely? This is probably one of those "wait for help" scenarios, at this point. :) |
This comment has been minimized.
This comment has been minimized.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Anything used in the implementation of a public stable const fn needs to be marked rustc_const_stable.
error: `ptr::metadata::from_raw_parts` is not yet stable as a const fn
|
260 | from_raw_parts(data.cast(), len)
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
rust/library/core/src/ptr/metadata.rs
Lines 108 to 110 in f5975e5
#[rustc_const_unstable(feature = "ptr_metadata", issue = "81513")] | |
#[inline] | |
pub const fn from_raw_parts<T: ?Sized>( |
That's reasonable. Is that something we/I can do in this case? Admittedly, it's not clear to me. |
☔ The latest upstream changes (presumably #95274) made this pull request unmergeable. Please resolve the merge conflicts. |
This comment has been minimized.
This comment has been minimized.
☔ The latest upstream changes (presumably #92686) made this pull request unmergeable. Please resolve the merge conflicts. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, you will need to add rustc_const_stable attributes for all the private functions getting called by these public functions. Whether it's something we can do depends on what functions end up needing to get rustc_const_stable added. That would be reviewed after the changes are made.
Ping from triage: FYI: when a PR is ready for review, send a message containing |
Signed-off-by: Toby Lawrence <[email protected]>
This comment has been minimized.
This comment has been minimized.
Signed-off-by: Toby Lawrence <[email protected]>
This comment has been minimized.
This comment has been minimized.
Signed-off-by: Toby Lawrence <[email protected]>
The job Click to see the possible cause of the failure (guessed by this bot)
|
I'm going to close this PR for now. Working through adjusting the const stability for the transitive functions landed me at having to do so for the |
Is there a problem with marking
|
…r=dtolnay Partially stabilize const_slice_from_raw_parts This doesn't stabilize methods working on mutable pointers. This pull request continues from rust-lang#94946. Pinging `@rust-lang/wg-const-eval` this because I use `rustc_allow_const_fn_unstable`. I believe this is justifiable as it's already possible to use `slice::from_raw_parts` in stable by abusing `transmute`. The stable alternative to this would be to provide a stable const implementation of `std::ptr::from_raw_parts` (as it can already be implemented in stable). ```rust use std::mem; #[repr(C)] struct Slice<T> { data: *const T, len: usize, } fn main() { let data: *const i32 = [1, 2, 3, 4].as_ptr(); let len = 4; println!("{:?}", unsafe { mem::transmute::<Slice<i32>, &[i32]>(Slice { data, len }) }); } ``` `@rustbot` modify labels: +T-libs-api
This doesn't close the tracking issue (#67456) as there's still the mutable variants to consider, but the immutable variants should seemingly be fine to stabilize.
Apologies if this stabilization PR is lacking something: it wasn't immediately clear if there was a different process for partial stabilizations.