Document transmutability of pointer types#2292
Open
traviscross wants to merge 7 commits into
Open
Conversation
The pointer-to-pointer cast rules and the wide-pointer validity rule both speak of the *metadata* of a pointer, but we hadn't explicitly defined the term (even though we had defined the contents of that metadata). Let's do that and link to it.
We refer to the unsized tail of a type, but we hadn't defined it. Let's do that and link to the definition.
The validity rule for the metadata of a wide reference, `Box<T>`, or raw pointer mentions `dyn Trait` and slice but had omitted `str`. Let's fix that.
We document that, for references and `Box<T>`, pointed-to values with slice or `str` metadata must be no larger than `isize::MAX`. We hadn't required this for pointed-to values with `dyn` metadata. It's tempting to think this isn't necessary since we separately require that the metadata point to a vtable generated by the compiler, which ensures the encoded size of the erased type is OK. But the bound is on the total size of the pointed-to value, including any sized prefix of a type with an unsized tail. Since the prefix combined with the size in the vtable can push us past the limit, we need the separate restriction. Let's apply the rule to both cases and add an admonition to remind ourselves of why this is needed.
We say that pointers to DSTs store metadata and what that metadata is for pointers to slices, `str`, and trait objects. But a struct or tuple with an unsized tail is itself a DST, and we hadn't said what the metadata is for pointers to these unsized types. Now that we've defined *metadata* and *unsized tail*, let's complete this enumeration.
We guarantee various things about the layout of pointers and references, but we'd made no guarantees of equivalence between two pointers to distinct unsized types that differ in the unsized tail. Let's make some useful guarantees about this.
Our rules for `as` casts document which pointer-to-pointer casts are valid. For unsized types, this validity is based on the compatibility of the pointer metadata. Using this and our layout equivalences, we can define when a pointer transmute will produce the same pointer value as would a cast. Let's define that.
This comment has been minimized.
This comment has been minimized.
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
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.
Our rules for
ascasts document which pointer-to-pointer casts are valid. For unsized types, this validity is based on the compatibility of the pointer metadata. Using this and our layout equivalences, we can define when a pointer transmute will produce the same pointer value as would a cast. Let's define that.I'm breaking this out from #2282 so that these may be considered in smaller pieces. This is stacked on #2291 (and on the ones it's stacked on).
cc @ehuss @RalfJung @Mark-Simulacrum