Skip to content

[pointer] Store validity in the referent type #2334

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

Merged
merged 1 commit into from
Feb 17, 2025

Conversation

joshlf
Copy link
Member

@joshlf joshlf commented Feb 12, 2025

Previously, validity was stored as part of the I: Invariants type
parameter on a Ptr<T, I>. In this commit, we migrate the validity to
being stored as the V in Ptr<V, I>; I now only stores aliasing and
alignment.

Bit validity is subtle, in that the pair of referent type and validity
invariant define a set of bit patterns which may appear in the Ptr's
referent. By encoding the validity in the referent type instead of in
the I parameter, we ensure that the validity of the referent is
captured entirely by a single type parameter rather than by a pair of
two separate type parameters. This makes future changes (e.g. #1359)
easier to model.

This idea was originally proposed in #1866 (comment)

Makes progress on #1866


This PR is on branch transmute-from.

@joshlf joshlf mentioned this pull request Feb 12, 2025
@codecov-commenter
Copy link

codecov-commenter commented Feb 12, 2025

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 89.34%. Comparing base (c43bbed) to head (7655869).

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #2334      +/-   ##
==========================================
+ Coverage   89.32%   89.34%   +0.02%     
==========================================
  Files          16       16              
  Lines        6023     6037      +14     
==========================================
+ Hits         5380     5394      +14     
  Misses        643      643              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@joshlf joshlf force-pushed the Ia73ca4e5dfb3b20f71ed72ffda24dd7450c427ba branch 3 times, most recently from 5d99011 to 1b77003 Compare February 13, 2025 22:54
@joshlf joshlf requested a review from jswrenn February 13, 2025 22:56
@@ -1050,7 +1064,7 @@ mod _casts {
// `UnsafeCell<T>` has the same in-memory representation as its
// inner type `T`. A consequence of this guarantee is that it is
// possible to convert between `T` and `UnsafeCell<T>`.
let ptr = unsafe { ptr.assume_validity::<I::Validity>() };
let ptr = unsafe { ptr.assume_validity::<V>() };
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe introduce a Validity::WithValidity<V> GAT that permits going from V<Inner = UnsafeCell<T>> to W<Inner = UnsafeCell<T>>?

@joshlf joshlf force-pushed the Ia73ca4e5dfb3b20f71ed72ffda24dd7450c427ba branch 2 times, most recently from 07239f8 to 0f07add Compare February 14, 2025 23:34
Previously, validity was stored as part of the `I: Invariants` type
parameter on a `Ptr<T, I>`. In this commit, we migrate the validity to
being stored as the `V` in `Ptr<V, I>`; `I` now only stores aliasing and
alignment.

Bit validity is subtle, in that the pair of referent type and validity
invariant define a set of bit patterns which may appear in the `Ptr`'s
referent. By encoding the validity in the referent type instead of in
the `I` parameter, we ensure that the validity of the referent is
captured entirely by a single type parameter rather than by a pair of
two separate type parameters. This makes future changes (e.g. #1359)
easier to model.

This idea was originally proposed in #1866 (comment)

Makes progress on #1866

gherrit-pr-id: Ia73ca4e5dfb3b20f71ed72ffda24dd7450c427ba
@joshlf joshlf force-pushed the Ia73ca4e5dfb3b20f71ed72ffda24dd7450c427ba branch from 0f07add to 7655869 Compare February 14, 2025 23:42
Copy link
Member Author

@joshlf joshlf left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Collaborator

@jswrenn jswrenn left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reviewed in-person; comments addressed.

@jswrenn jswrenn added this pull request to the merge queue Feb 17, 2025
Merged via the queue into main with commit 28b55b9 Feb 17, 2025
69 checks passed
@jswrenn jswrenn deleted the Ia73ca4e5dfb3b20f71ed72ffda24dd7450c427ba branch February 17, 2025 22:06
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants