Replace feature(layout_for_ptr) with feature(layout_for_meta)

[CAD97]

Proposal

Problem statement

Tracking issue: rust-lang/rust#69835

Current unstable API

// core;:mem
unsafe fn size_of_val_raw<T: ?Sized>(val: *const T) -> usize;
unsafe fn align_of_val_raw<T: ?Sized>(val: *const T) -> usize;

// core::alloc::Layout
unsafe fn for_value_raw<T: ?Sized>(t: *const T) -> Self;

Proposed unstable API

// core;:ptr
unsafe fn size_for_pointee<T: ?Sized>(meta: <T as Pointee>::Metadata) -> usize;
unsafe fn align_for_pointee<T: ?Sized>(meta: <T as Pointee>::Metadata) -> usize;

// core::alloc::Layout
unsafe fn for_pointee<T: ?Sized>(meta: <T as Pointee>::Metadata) -> Self;

(bikeshed away)

Motivation

Per T-lang, these APIs fit nicely into the general story of ptr_metadata. The metadata is currently all that is required to calculate pointee layout, and there are potential language issues with allowing layout calculation to access the data pointer.

Solution sketches

See above for the proposed unstable API change.

Alternatively, the ptr_metadata APIs could all be adjusted to deal in a ptr::Metadata<T> wrapper type (c.f. rust-lang/rust#97052), and then size_of/align_of/layout methods could be provided like they are for DynMetadata. Unfortunately, they cannot be made (infallibly) safe, because it is perfectly safe/acceptable to cast raw pointers such that their metadata/type combo describes a pointee larger than the address space.

The former is the smaller change. The latter is potentially a more coherent design.

Of course, just providing all of the entry points is also an option.

Links and related work

• Implement pointee metadata unsizing via a TypedMetadata<T> container rust#97052 : proposes a ptr::Metadata<T> type for the purpose of coercions, which cannot be provided for <T as Pointee>::Metadata
• Tracking Issue for layout information behind pointers rust#69835 : layout_for_ptr tracking issue
• Tracking Issue for pointer metadata APIs rust#81513 : ptr_metadata tracking issue
• Note design constraints on hypothetical DynSized lang-team#166 : describes what support for custom pointee layout might look like
• Experiment: Make intrinsic::size_of(slice) saturate rust#95832 : experiment to partially measure the cost of a fallible metadata -> Layout conversion

What happens now?

This issue is part of the libs-api team API change proposal process. Once this issue is filed the libs-api team will review open proposals in its weekly meeting. You should receive feedback within a week or two.

[m-ou-se]

This seems to assume the size of the object can fully be determined by the metadata, without the object pointer. But don't we want to support custom dynamically sized types in the future, like a thin &CStr, where the pointer part is necessary to determine the size? How would that work?

[joshtriplett]

Also, it sounds like this ACP is referencing that lang team design note to say that there are problems with having types that require reading the pointee to get the size, but with my lang hat on, I don't understand how that note implies such problems.