-
Notifications
You must be signed in to change notification settings - Fork 107
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
[pointer] Relax UnsafeCell requirements (#1211)
Previously, we required there to always be "`UnsafeCell` agreement" between any `Ptr`s or references referencing a given region of memory. This was based on an overly-strict interpretation of the semantics of `UnsafeCell`. In this commit, we relax `Ptr` to only require "`UnsafeCell` agreement" when the aliasing model is `Shared`. All of the places that our internal invariants are "consumed" - ie, where we use them as safety preconditions for calling unsafe functions defined outside our crate - this relaxation is sufficient. This is based on what we (@jswrenn and I) believe to be a more accurate model of the semantics of `UnsafeCell`s. In particular, `UnsafeCell`s do not affect the semantics of loads or stores in Rust. All they do is affect the semantics of shared references. In particular, Rust assumes that the referent of a shared reference will not be stored to during the lifetime of any shared reference, but this assumption is not made for bytes which are covered by an `UnsafeCell`. This is entirely a runtime property. If two references refer to the same memory, but disagree on whether that memory is covered by an `UnsafeCell`, this results in UB if the `UnsafeCell` is used to store to the memory, violating the expectations of the non-`UnsafeCell` shared reference. This commit is consistent with the runtime nature of this property, but is inconsistent with Stacked Borrows (rust-lang/unsafe-code-guidelines#455). However, this is considered to be a bug in Stacked Borrows.
- Loading branch information
Showing
8 changed files
with
172 additions
and
277 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Large diffs are not rendered by default.
Oops, something went wrong.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters