Re: [PATCH 1/4] rust: add projection infrastructure

["Benno Lossin" <lossin@kernel.org>]

On Sat Feb 14, 2026 at 11:36 AM CET, Gary Guo wrote:
> On 2026-02-14 09:53, Benno Lossin wrote:
>> On Sat Feb 14, 2026 at 6:33 AM CET, Gary Guo wrote:
>>> +// SAFETY: `proj` invokes `f` with valid allocation.
>>> +unsafe impl<T> ProjectField<false> for T {
>>> +    #[inline(always)]
>>> +    unsafe fn proj<F>(base: *mut Self, f: impl FnOnce(*mut Self) -> *mut F) -> *mut F {
>>> +        // Create a valid allocation to start projection, as `base` is not necessarily so.
>>> +        let mut place = MaybeUninit::uninit();
>>> +        let place_base = place.as_mut_ptr();
>>> +        let field = f(place_base);
>>> +        // SAFETY: `field` is in bounds from `base` per safety requirement.
>>> +        let offset = unsafe { field.byte_offset_from(place_base) };
>>> +        base.wrapping_byte_offset(offset).cast()
>>> +    }
>> 
>> There are several limitations with this impl. I don't think we can do
>> anything about them, but it's probably good to list them somewhere:
>> 1. We do not support projecting fields of unsized types, so `MyStruct<dyn Trait>`.
>>    (note that slices are supported with `ProjectIndex`)
>> 2. Since this creates a `MaybeUninit<T>` on the stack, only small `T`
>>    are supported. I'm not sure how much of this will be optimized away,
>>    but it might be the case that it is not. Projecting in the same
>>    function call stack multiple times might result in overrunning the
>>    stack pretty quickly.
>
> I've verified codegen and haven't managed to get this to actually generate `T` on the stack.
> LLVM always figures out that the offset is the only thing that matters and optimize away
> everything. `memoffset` crate also creates a temporary `MaybeUninit`, and given that it was
> very widely used before `offset_of!` is stable, I think we should be able to rely on this being
> okay even for large types.

Oh that's neat.

> Note that I've taken care to mark everything `#[inline(always)]` when possible, even
> closures passed to `proj`.

Yeah I saw that.

People might still encounter this issue in some fringe situation. I'm
not too worried, since klint can warn about the stack frame being too
large.

Speaking of klint, could it be possible to have a
`#[klint::optimized_away]` attribute that we can put on the `let place`,
klint would then error (or warn) when it's not optimized away (the name
isn't great :)

>
>> 3. The `wrapping_byte_offset` function generates potentially worse
>>    codegen when `base` points into a real allocation.
>
> I'm highly skeptical that we'll lose any optimization, but this is indeed
> a possibility in theory.

I remember some Rust codegen expert wanting to use `offset` instead of
`wrapping_offset` in the projection operator of `NonNull` and raw
pointers (the original RFC I think).

>>> +    ($ptr:expr, $($proj:tt)*) => {{
>>> +        let ptr = $ptr.cast_mut();
>> 
>> This allows `$ptr` to be a random type with a `cast_mut` function. How
>> about:
>> 
>>     let ptr: *const _ = $ptr;
>>     let ptr: *mut _ = ::core::ptr::cast_mut(ptr);
>
> I think `<*const _>::cast_mut($ptr)` probably would also do.

That also works.

Cheers,
Benno