The `ptr::Pointee` design must incorporate layout info about rust HOT 5 CLOSED

I don't think I get it. If I have an &T, which I need to call the new method on Pointee, I can easily call Layout::for_value to get the corresponding layout. No need to involve the Pointee trait I think?

Your proposal lacks a motivation statement for what users of the standard library should be able to do that they currently can't do. You are suggesting to re-implement the way size_of etc work internally, but users shouldn't have to care about that. That motivation needs to come first, before you give any of the technical details for how to achieve this. (See the usual format of our RFCs -- what you're doing here is basically writing an RFC.)

unsafe impl Pointee for CStr {

I think you are incorporating some kind of hypothetical future version of CStr here? For the current CStr this makes little sense. You referenced this from #81513 but this part makes it sound like it is unrelated to the metadata APIs for the current types and only relevant for hypothetical future custom DST?

Again, all that is something that should be explained in the first paragraph of your proposal. Don't make us guess. :)

Miri can check custom layouts against the struct's backing memory on construct and on every pointer cast to the type, ensuring the referenced memory region is always valid and that the pointer in question is correctly aligned.

I don't know what you mean by that. Please give an example of a bug Miri currently cannot find, but would be able to find with your proposal.

from rust.

You're essentially co-opting Pointee to be DynSized, which, sure, okay, that makes some sense, but you don't need to be able to know the size of something to point at it. You do to directly own it, but opaque/incomplete types that can't be owned/moved due to unknown size are a useful API design tool.

If the final field does not implement Aligned but does implement Pointee, the auto-generated implementation returns essentially static_prefix.extend(final_field.layout()).unwrap().0.

This definition has the usual issue for Mutex<CStr>. How exactly is UnsafeCell<CStr> going to get &T to call Pointee::layout(&T)?

It's also impossible to access the field without first knowing its alignment, as that impacts its offset in the structure. Along the same lines, Arc<T> requires to be able to get size from a pointer to dropped T. It's FCP decided that this is a thing which is possible to do for any dynamically sized type.

The operation really just wants to be possible from just <T as Pointee>::Metadata.

from rust.

The operation really just wants to be possible from just ::Metadata.

Right, what would make a lot of sense is

fn size_of_meta<T: Pointee>(meta: T::Metadata) -> usize

That corresponds pretty well to the underlying primitive in the compiler.

Do we have an issue tracking something like that?

from rust.

@RalfJung

I glossed over a lot here. My apologies.

[...] what you're doing here is basically writing an RFC.

It's kinda like an RFC for an RFC. Because of this, I wasn't sure whether to post this here, in https://internals.rust-lang.org, or as a proper RFC/MCP.

If you know of a better way to raise such a major question around the pointer metadata RFC/feature, please let me know and I'll move this accordingly.

I'll be the first to admit I was somewhat lost on where to post this. And my being lost is admittedly part of how this turned out to be a bit of a stream of consciousness.

I don't think I get it. If I have an &T, which I need to call the new method on Pointee, I can easily call Layout::for_value to get the corresponding layout. No need to involve the Pointee trait I think?

That's true from the average user's perspective. However, there's use in making it pluggable.

Your proposal lacks a motivation statement for what users of the standard library should be able to do that they currently can't do. [...]

I'll defer to rust-lang/rfcs#3536 on rationale for why size_of_val should be pluggable.

Some degree of alignment pluggability is also needed so FFI types like CStr can feasibly switch to raw pointers.

I went with a layout method returning a Layout because it was easy to stub out. You could also just use alignment attributes on opaque types and do the rest statically.

I think you are incorporating some kind of hypothetical future version of CStr here?

Yeah, I should've clarified the hypothetical nature of it. I almost added a note about that dozens of times and simply forgot. All those implementations in that code block are hypothetical.

Miri can check custom layouts against the struct's backing memory on construct and on every pointer cast to the type, ensuring the referenced memory region is always valid and that the pointer in question is correctly aligned.

I don't know what you mean by that. Please give an example of a bug Miri currently cannot find, but would be able to find with your proposal.

The idea is to check that stuff like Gc<dyn Trait> and Gc<WideCStr> align their allocated pointer correctly and expose the right chunk of memory from Deref.

from rust.

@CAD97 I'll bring those up in rust-lang/rfcs#3536 and try to come to a solution there. This was admittedly very premature, despite me spending most of a day on it.

from rust.