-
Notifications
You must be signed in to change notification settings - Fork 13.4k
rephrase UnsafeCell doc #48201
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
rephrase UnsafeCell doc #48201
Changes from 3 commits
f1c1fc2
b9b8249
273166e
d9b8724
50f5ea9
ff6754c
78789ad
fe557ee
fbcd2f5
55be283
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -1164,11 +1164,12 @@ impl<'a, T: ?Sized + fmt::Display> fmt::Display for RefMut<'a, T> { | |
/// The compiler makes optimizations based on the knowledge that `&T` is not mutably aliased or | ||
/// mutated, and that `&mut T` is unique. When building abstractions like `Cell`, `RefCell`, | ||
/// `Mutex`, etc, you need to turn these optimizations off. `UnsafeCell` is the only legal way | ||
/// to do this. When `UnsafeCell<T>` is immutably aliased, it is still safe to obtain a mutable | ||
/// reference to its interior and/or to mutate it. However, it is up to the abstraction designer | ||
/// to ensure that no two mutable references obtained this way are active at the same time, and | ||
/// that there are no active mutable references or mutations when an immutable reference is obtained | ||
/// from the cell. This is often done via runtime checks. | ||
/// to do this. When `UnsafeCell<T>` itself is immutably aliased, it is still safe to obtain | ||
/// a mutable reference to its interior and/or to mutate the interior. However, it is up to | ||
/// the abstraction designer to ensure that no two mutable references obtained this way are active | ||
/// at the same time, there are no active immutable reference when a mutable reference is obtained | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. These rules are kind of confusingly stated. I think it should be something like the following: There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'll try to merge three rules into one, so it will be easier to follow. |
||
/// from the cell, and that there are no active mutable references or mutations when an immutable | ||
/// reference is obtained. This is often done via runtime checks. | ||
/// | ||
/// Note that while mutating or mutably aliasing the contents of an `& UnsafeCell<T>` is | ||
/// okay (provided you enforce the invariants some other way); it is still undefined behavior | ||
|
@@ -1240,9 +1241,9 @@ impl<T: ?Sized> UnsafeCell<T> { | |
/// Gets a mutable pointer to the wrapped value. | ||
/// | ||
/// This can be cast to a pointer of any kind. | ||
/// Ensure that the access is unique when casting to | ||
/// `&mut T`, and ensure that there are no mutations or mutable | ||
/// aliases going on when casting to `&T` | ||
/// Ensure that the access is unique (no active references, mutable or not) | ||
/// when casting to `&mut T`, and ensure that there are no mutations | ||
/// or mutable aliases going on when casting to `&T` | ||
/// | ||
/// # Examples | ||
/// | ||
|
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.
Can you reformat this as a list? Several of the entries are long, and the sentence becomes hard to follow.