Tracking issue for `&mut T` in const contexts (const_mut_refs) #57349

ExpHP · 2019-01-05T03:56:52Z

The const_mut_refs feature gate allows the following in const context:

&mut arguments
mutable (re)borrows and raw pointers (&mut and addr_of_mut! expressions)
dereferencing mutable references and raw pointers (* expressions)

Remaining work

Anonymous allocations in statics get duplicated for multiple codegen units #79738 static mut FOO: &'static mut i32 = &mut 42; is problematic, because LLVM currently duplicates the inner mutable reference when you do static mut BAR: &'static mut i32 = FOO;. It would probably suffice to give all nested allocations in a static names relative to their original static item. Named allocations are neither deduplicated nor duplicated.
Currently the interning of the final result of the const relies on types more than it should, given that transmute is available in consts. Fixed in const-eval interning: get rid of type-driven traversal #119044.
Mutable reference protected by a mutex in static context is considered UB #120450
Figure out what to do with regression: encountered mutable pointer in final value when "outer scope" rule applies in const/static with interior mutability #121610: that's happening in const-eval interning: accept interior mutable pointers in final value #128543
Adjust documentation: const_eval: update for const_mut_refs and const_refs_to_cell stabilization reference#1590
Stabilization PR: Stabilize &mut (and *mut) as well as &Cell (and *const Cell) in const #129195

Open questions

can we stabilize this without figuring out the const heap story? -> yes, no reason this has to wait for const_heap
can we stabilize this without cranelift and codegen_gcc support? ICE: hir: index out of bounds: the len is 5 but the index is 5 #122399, ICE: hir: index out of bounds: the len is 5 but the index is 5 rustc_codegen_gcc#473

The text was updated successfully, but these errors were encountered:

leading_zeroes and this kind of functions are const-ready since 1.34.0 We neeed rust-lang/rust#57349 to constantize further.

Stabilize `&mut` (and `*mut`) as well as `&Cell` (and `*const Cell`) in const This stabilizes `const_mut_refs` and `const_refs_to_cell`. That allows a bunch of new things in const contexts: - Mentioning `&mut` types - Creating `&mut` and `*mut` values - Creating `&T` and `*const T` values where `T` contains interior mutability - Dereferencing `&mut` and `*mut` values (both for reads and writes) The same rules as at runtime apply: mutating immutable data is UB. This includes mutation through pointers derived from shared references; the following is diagnosed with a hard error: ```rust #[allow(invalid_reference_casting)] const _: () = { let mut val = 15; let ptr = &val as *const i32 as *mut i32; unsafe { *ptr = 16; } }; ``` The main limitation that is enforced is that the final value of a const (or non-`mut` static) may not contain `&mut` values nor interior mutable `&` values. This is necessary because the memory those references point to becomes *read-only* when the constant is done computing, so (interior) mutable references to such memory would be pretty dangerous. We take a multi-layered approach here to ensuring no mutable references escape the initializer expression: - A static analysis rejects (interior) mutable references when the referee looks like it may outlive the current MIR body. - To be extra sure, this static check is complemented by a "safety net" of dynamic checks. ("Dynamic" in the sense of "running during/after const-evaluation, e.g. at runtime of this code" -- in contrast to "static" which works entirely by looking at the MIR without evaluating it.) - After the final value is computed, we do a type-driven traversal of the entire value, and if we find any `&mut` or interior-mutable `&` we error out. - However, the type-driven traversal cannot traverse `union` or raw pointers, so there is a second dynamic check where if the final value of the const contains any pointer that was not derived from a shared reference, we complain. This is currently a future-compat lint, but will become an ICE in rust-lang#128543. On the off-chance that it's actually possible to trigger this lint on stable, I'd prefer if we could make it an ICE before stabilizing const_mut_refs, but it's not a hard blocker. This part of the "safety net" is only active for mutable references since with shared references, it has false positives. Altogether this should prevent people from leaking (interior) mutable references out of the const initializer. While updating the tests I learned that surprisingly, this code gets rejected: ```rust const _: Vec<i32> = { let mut x = Vec::<i32>::new(); //~ ERROR destructor of `Vec<i32>` cannot be evaluated at compile-time let r = &mut x; let y = x; y }; ``` The analysis that rejects destructors in `const` is very conservative when it sees an `&mut` being created to `x`, and then considers `x` to be always live. See [here](rust-lang#65394 (comment)) for a longer explanation. `const_precise_live_drops` will solve this, so I consider this problem to be tracked by rust-lang#73255. Cc `@rust-lang/wg-const-eval` `@rust-lang/lang` Cc rust-lang#57349 Cc rust-lang#80384

Rollup merge of rust-lang#129195 - RalfJung:const-mut-refs, r=fee1-dead Stabilize `&mut` (and `*mut`) as well as `&Cell` (and `*const Cell`) in const This stabilizes `const_mut_refs` and `const_refs_to_cell`. That allows a bunch of new things in const contexts: - Mentioning `&mut` types - Creating `&mut` and `*mut` values - Creating `&T` and `*const T` values where `T` contains interior mutability - Dereferencing `&mut` and `*mut` values (both for reads and writes) The same rules as at runtime apply: mutating immutable data is UB. This includes mutation through pointers derived from shared references; the following is diagnosed with a hard error: ```rust #[allow(invalid_reference_casting)] const _: () = { let mut val = 15; let ptr = &val as *const i32 as *mut i32; unsafe { *ptr = 16; } }; ``` The main limitation that is enforced is that the final value of a const (or non-`mut` static) may not contain `&mut` values nor interior mutable `&` values. This is necessary because the memory those references point to becomes *read-only* when the constant is done computing, so (interior) mutable references to such memory would be pretty dangerous. We take a multi-layered approach here to ensuring no mutable references escape the initializer expression: - A static analysis rejects (interior) mutable references when the referee looks like it may outlive the current MIR body. - To be extra sure, this static check is complemented by a "safety net" of dynamic checks. ("Dynamic" in the sense of "running during/after const-evaluation, e.g. at runtime of this code" -- in contrast to "static" which works entirely by looking at the MIR without evaluating it.) - After the final value is computed, we do a type-driven traversal of the entire value, and if we find any `&mut` or interior-mutable `&` we error out. - However, the type-driven traversal cannot traverse `union` or raw pointers, so there is a second dynamic check where if the final value of the const contains any pointer that was not derived from a shared reference, we complain. This is currently a future-compat lint, but will become an ICE in rust-lang#128543. On the off-chance that it's actually possible to trigger this lint on stable, I'd prefer if we could make it an ICE before stabilizing const_mut_refs, but it's not a hard blocker. This part of the "safety net" is only active for mutable references since with shared references, it has false positives. Altogether this should prevent people from leaking (interior) mutable references out of the const initializer. While updating the tests I learned that surprisingly, this code gets rejected: ```rust const _: Vec<i32> = { let mut x = Vec::<i32>::new(); //~ ERROR destructor of `Vec<i32>` cannot be evaluated at compile-time let r = &mut x; let y = x; y }; ``` The analysis that rejects destructors in `const` is very conservative when it sees an `&mut` being created to `x`, and then considers `x` to be always live. See [here](rust-lang#65394 (comment)) for a longer explanation. `const_precise_live_drops` will solve this, so I consider this problem to be tracked by rust-lang#73255. Cc `@rust-lang/wg-const-eval` `@rust-lang/lang` Cc rust-lang#57349 Cc rust-lang#80384

workingjubilee · 2024-09-19T03:04:20Z

const fn API currently awaiting checkboxes:

const str::{as_bytes_mut,as_mut_ptr}: Tracking Issue for const_str_as_mut #130086 (comment)
const slice::split_at_mut: Tracking Issue for feature(const_slice_split_at_mut) #101804 (comment)
const slice::{first,last}_mut: Tracking Issue for #![feature(const_slice_first_last)] #83570 (comment)
const mem::replace: Tracking Issue for const_replace #83164 (comment)
const str::from_utf8_unchecked_mut: Tracking Issue for str::from_utf8_unchecked_mut as a const fn #91005 (comment)
const UnsafeCell::get_mut Tracking Issue for #![feature(const_unsafecell_get_mut)] #88836 (comment)

RalfJung · 2024-09-19T06:14:20Z

There's more:

And things that only very recently even got implemented (updated based on comments below):

bjoernager · 2024-09-19T08:05:29Z

There's also char::encode_utf8: #130512

RalfJung · 2024-09-19T08:18:54Z

This has just been implemented. Let's maybe let it bake on nightly for a bit?

onestacked · 2024-09-19T08:56:59Z

#67456 needs an FCP started for Stabilization PR #130403

…dtolnay Mark `char::make_ascii_uppercase` and `char::make_ascii_lowercase` as const. Relevant tracking issue: rust-lang#130698 The `make_ascii_uppercase` and `make_ascii_lowercase` methods in `char` should be marked "const." With the stabilisation of [`const_mut_refs`](rust-lang#57349), this simply requires adding the `const` specifier to the function signatures.

Mark `char::make_ascii_uppercase` and `char::make_ascii_lowercase` as const. Relevant tracking issue: #130698 The `make_ascii_uppercase` and `make_ascii_lowercase` methods in `char` should be marked "const." With the stabilisation of [`const_mut_refs`](rust-lang/rust#57349), this simply requires adding the `const` specifier to the function signatures.

…om_raw_parts_mut, r=workingjubilee Stabilize `const_slice_from_raw_parts_mut` Stabilizes rust-lang#67456, since rust-lang#57349 has been stabilized. Stabilized const API: ```rust // core::ptr pub const fn slice_from_raw_parts_mut<T>(data: *mut T, len: usize) -> *mut [T]; // core::slice pub const unsafe fn from_raw_parts_mut<'a, T>(data: *mut T, len: usize) -> &'a mut [T]; // core::ptr::NonNull pub const fn slice_from_raw_parts(data: NonNull<T>, len: usize) -> Self ``` Closes rust-lang#67456. r? libs-api

…_raw_parts_mut, r=workingjubilee Stabilize `const_slice_from_raw_parts_mut` Stabilizes rust-lang#67456, since rust-lang#57349 has been stabilized. Stabilized const API: ```rust // core::ptr pub const fn slice_from_raw_parts_mut<T>(data: *mut T, len: usize) -> *mut [T]; // core::slice pub const unsafe fn from_raw_parts_mut<'a, T>(data: *mut T, len: usize) -> &'a mut [T]; // core::ptr::NonNull pub const fn slice_from_raw_parts(data: NonNull<T>, len: usize) -> Self ``` Closes rust-lang#67456. r? libs-api

…om_raw_parts_mut, r=workingjubilee Stabilize `const_slice_from_raw_parts_mut` Stabilizes rust-lang#67456, since rust-lang#57349 has been stabilized. Stabilized const API: ```rust // core::ptr pub const fn slice_from_raw_parts_mut<T>(data: *mut T, len: usize) -> *mut [T]; // core::slice pub const unsafe fn from_raw_parts_mut<'a, T>(data: *mut T, len: usize) -> &'a mut [T]; // core::ptr::NonNull pub const fn slice_from_raw_parts(data: NonNull<T>, len: usize) -> Self ``` Closes rust-lang#67456. r? libs-api

Rollup merge of rust-lang#130403 - eduardosm:stabilize-const_slice_from_raw_parts_mut, r=workingjubilee Stabilize `const_slice_from_raw_parts_mut` Stabilizes rust-lang#67456, since rust-lang#57349 has been stabilized. Stabilized const API: ```rust // core::ptr pub const fn slice_from_raw_parts_mut<T>(data: *mut T, len: usize) -> *mut [T]; // core::slice pub const unsafe fn from_raw_parts_mut<'a, T>(data: *mut T, len: usize) -> &'a mut [T]; // core::ptr::NonNull pub const fn slice_from_raw_parts(data: NonNull<T>, len: usize) -> Self ``` Closes rust-lang#67456. r? libs-api

Rudxain · 2024-10-29T21:02:22Z

Is there a discussion thread for this? I've searched multiple RFCs, but I can't find a single one mentioning iterators. If I'm not mistaken, this feature is a big step forward to support const iteration. We already have const loops, so I can feel core::iter is soon becoming const too!

Lokathor · 2024-10-29T21:06:26Z

requiring const trait impls means that normal iterators are most likely rather far out.

RalfJung · 2024-10-29T21:10:56Z

Iterators are still blocked on being able to call trait functions in const, which is unfortunately quite tricky. See:

Also, closed issue are not a support forum, so I'll lock this -- too many people get notifications in this one to make it a good place for support questions.

Centril changed the title ~~Mutation in const fn~~ Tracking issue for &mut T in const fn Jan 5, 2019