Skip to content
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 Cell::as_array_of_cells #88248

Open
1 of 3 tasks
oconnor663 opened this issue Aug 23, 2021 · 5 comments
Open
1 of 3 tasks

Tracking Issue for Cell::as_array_of_cells #88248

oconnor663 opened this issue Aug 23, 2021 · 5 comments
Labels
A-array Area: [T; N] C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.

Comments

@oconnor663
Copy link
Contributor

oconnor663 commented Aug 23, 2021

Feature gate: #![feature(as_array_of_cells)]

This is a tracking issue for Cell::as_array_of_cells, the const-generic counterpart to the existing Cell::as_slice_of_cells.

Public API

impl<T, const N: usize> Cell<[T; N]> {
    pub fn as_array_of_cells(&self) -> &[Cell<T>; N] { ... }
}

// Example

let mut array: [i32; 3] = [1, 2, 3];
let cell_array: &Cell<[i32; 3]> = Cell::from_mut(&mut array);
let array_cell: &[Cell<i32>; 3] = cell_array.as_array_of_cells();

Steps / History

Unresolved Questions

  • None yet.
@oconnor663 oconnor663 added C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. labels Aug 23, 2021
@workingjubilee workingjubilee added the A-array Area: [T; N] label Mar 7, 2023
@pierzchalski
Copy link
Contributor

@oconnor663 Do you know who would be the right person to @ in order to get this reviewed/FCP'd? Given the existence of as_slice_of_cells I don't think we'll have a blocking discussion on the name or semantics, at least.

@pierzchalski
Copy link
Contributor

Wait, can I just do @rfcbot needs-fcp

@TOETOE55
Copy link

TOETOE55 commented Jan 9, 2024

Does the following code violate the readonly constraint of arr_of_cells: &[Cell<i32>]?

 let mut arr = [0; 10];
 let cell_arr = Cell::from_mut(&mut arr);
 let arr_of_cells = cell_arr.as_array_of_cells();
 cell_arr.set([1; 10]);
// arr_of_cells was changed.
 dbg!(arr_of_cells);

@oconnor663
Copy link
Contributor Author

@TOETOE55 Miri is ok with it at least. I could be totally wrong, but I think Miri sees these things in terms of bytes, and all the bytes in this case are covered by UnsafeCell, and that might be why it's ok.

@scottmcm what needs to be done to move to FCP?

@TOETOE55
Copy link

TOETOE55 commented Jan 10, 2024

The following code also passes Miri's checks
, but whether this should be UB is questionable. If I remember correctly, the current rule for the checks is that &T is readonly only when T does not contain UnsafeCell.

use core::cell::Cell;

fn main() {
    let mut opt = Some(1);
    let cell_opt = Cell::from_mut(&mut opt);
    let opt_cell = unsound(&cell_opt);
    dbg!(opt_cell.as_ref().unwrap());
    cell_opt.set(None);
    dbg!(opt_cell);
}

fn unsound<T>(opt: &Cell<Option<T>>) -> &Option<Cell<T>> {
    unsafe { &*(opt as *const Cell<Option<T>> as *const Option<Cell<T>>) }
}

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-array Area: [T; N] C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

4 participants