-
Notifications
You must be signed in to change notification settings - Fork 58
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
Decide on validity for metadata of wide pointer/reference with slice tail #510
Comments
No objections here and seconded that this is good to FCP Most cases that require validity will also retag the reference (thus require dereferencability which implies the same metadata constraints), with the exception being |
The function could always do a conversion to another metadata format, I suppose.
But this seems justification enough. As far as the difference of the validity invariant, I think that it is fine: |
Kind of... there's the point @CAD97 mentioned about But for slices I think that's just fine, with the semantics the way I proposed them above. |
Like a very... interesting... spelling of |
Under the above semantics, |
Let's get the show started, then. |
...does rfcbot not listen to this repo? |
IIRC it doesn't have a hook but instead just checks every few hours or so. |
However, I thought it did the check every full hour. Maybe the command is wrong. I took it from the docs, but last time I used a different command... |
Team member @RalfJung has proposed to merge this. The next step is review by the rest of the tagged team members: No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See this document for info about what commands tagged team members can give me. |
The only crate I'm aware of that tries to violate this requirement is https://crates.io/crates/deepmesa-collections, and that crate tries to do so by calling |
rfcbot is unchecking our boxes. |
I have filed deepmesa/deepmesa-rs#14 as a courtesy to the author and a notification to anyone who inspects the repo. |
let's try @rfcbot reviewed |
Yeah, then at least we can see in the log who approved, even if rfcbot unchecks boxes again |
@rfcbot reviewed |
🔔 This is now entering its final comment period, as per the review above. 🔔 |
Given that we want to hold open the possibility that the validity invariants of |
All of this applies to sized and unsized types equally, so I don't think it is part of this discussion. All of this is a property of the pointer part of the wide pointer, but this issue is about the metadata part and only the metadata part. Maybe validity of the pointer part depends on the value of the metadata part, but certainly not the other way around, so the pointer part is irrelevant here. |
Thanks for writing this up! It makes sense to me, and is much clearer in phrasing than my attempt in that rust issue :P |
The final comment period, with a disposition to merge, as per the review above, is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. This will be merged soon. |
Great, thanks all. :) The issue can be closed then. |
Reference PR: rust-lang/reference#1499 |
This is a part of #166, needed to unblock rust-lang/rust#121965 and rust-lang/rust#116542.
A type
T
has "slice tail" if it is unsized and its last field (recursively descending through structs/tuples) is of the shape[U]
. For such types, we say that*const T
and*mut T
is exactly the same as that ofusize
.&T
and&mut T
is that ofusize
with the further constraint that the total size of aT
with that metadata must not exceedisize::MAX
.The representation relation is otherwise that of an integer (so, what happens when the metadata has provenance matches what happens when a
usize
has provenance -- we haven't decided what exactly that will be, but it should be consistent).Rationale:
slice_from_raw_parts
is a stable safe function that can construct a wide raw slice pointer with an arbitrary value for its metadata.I think the only possibly controversial point here is that the validity invariant is not the same for metadata of
*const [U]
and&[U]
. However, given that the validity invariant is already not the same for the data part of these (obviously), maybe that's not so surprising?I am not including vtables in this as I think we have more discussing to do there.
@rust-lang/opsem what do you think? Any objections to moving to FCP swiftly?
The text was updated successfully, but these errors were encountered: