[pointer] Clarify semantics of aliasing invariants (#1889) #2378
Conversation
This file contains hidden or 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
|
Backporting #1889 |
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## v0.8.x #2378 +/- ##
==========================================
+ Coverage 87.47% 87.82% +0.34%
==========================================
Files 16 16
Lines 6182 6159 -23
==========================================
+ Hits 5408 5409 +1
+ Misses 774 750 -24 ☔ View full report in Codecov by Sentry. |
Previously, we supported the `AtLeast` bound, which was used to describe a subset relationship in which `I: AtLeast<J>` implied that `I` as at least as restrictive as `J`. However, as described in #1866, this incorrectly models invariants as monotonic. In reality, invariants both provide guarantees but also *require* guarantees. This commit takes a step in the direction of resolving #1866 by removing `AtLeast`. Uses of `AtLeast<Shared>` are replaced by a new `Reference` trait, which is implemented for `Shared` and `Exclusive`. This serves two purposes: First, it makes it explicit what this bound means. Previously, `AtLeast<Shared>` had an ambiguous meaning, while `Reference` means precisely that an invariant is either `Shared` or `Exclusive` and nothing else. Second, it paves the way for #1183, in which we may add new aliasing invariants which convey ownership. In that case, it will be important for existing methods to add `Reference` bounds when those methods would not be sound in the face of ownership semantics. We also inline the items in the `invariant` module, which were previously generated by macro. The addition of the `Reference` trait did not play nicely with that macro, and we will likely need to go further from the macro in order to fix #1839 – this fix will likely require making aliasing invariants meaningfully different than other invariants, for example by adding an associated type. Makes progress on #1866 gherrit-pr-id: I86ef959643b97a34da81bf55a1fed5060b9cf6b2
jswrenn
approved these changes
Feb 24, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Previously, we supported the
AtLeastbound, which was used to describe a subset relationship in whichI: AtLeast<J>implied thatIas at least as restrictive asJ. However, as described in #1866, this incorrectly models invariants as monotonic. In reality, invariants both provide guarantees but also require guarantees.This commit takes a step in the direction of resolving #1866 by removing
AtLeast. Uses ofAtLeast<Shared>are replaced by a newReferencetrait, which is implemented forSharedandExclusive. This serves two purposes: First, it makes it explicit what this bound means. Previously,AtLeast<Shared>had an ambiguous meaning, whileReferencemeans precisely that an invariant is eitherSharedorExclusiveand nothing else. Second, it paves the way for #1183, in which we may add new aliasing invariants which convey ownership. In that case, it will be important for existing methods to addReferencebounds when those methods would not be sound in the face of ownership semantics.We also inline the items in the
invariantmodule, which were previously generated by macro. The addition of theReferencetrait did not play nicely with that macro, and we will likely need to go further from the macro in order to fix #1839 – this fix will likely require making aliasing invariants meaningfully different than other invariants, for example by adding an associated type.Makes progress on #1866
gherrit-pr-id: I86ef959643b97a34da81bf55a1fed5060b9cf6b2