cannot use mem::offset_of! with unions due to ManuallyDrop interfering

[anderspapitto]

When a union contains a non-Copy variant, the compiler forces the user to wrap it in ManuallyDrop. ManuallyDrop is guaranteed to have the same layout as the underlying type, but it is opaque to offset_of! because the value field is private.

here is an example that fails to compile

#![feature(offset_of_nested)]
use core::mem;
struct X { foo: usize }
union N { X: mem::ManuallyDrop<X> }
const o: usize = mem::offset_of!(N, X.value.foo);

playground link: (https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=84fadd9f1808d5ff7b52de9e1f0ab6b4)

[fmease]

This is not strictly a bug but a limitation or an oversight (one that should of course be solved in some way). According to https://rust-lang.github.io/rfcs/3308-offset_of.html#reference-level-explanation, the field must be directly defined on the given type (so no implicit dereferences through Deref) and public enough to access.

[fmease]

I'm pretty sure taking Deref into consideration would drastically change the implementation of offset_of if that's even possible at all (→ DerefPure ^^').

[fmease]

cc @thomcc

[anderspapitto]

rather than Deref, I'd guess that any fix would build on top of repr(transparent)

[fmease]

Well, somehow the compiler needs to know how to get to field foo on X coming from union N.
Of course, the compiler could perform a fake deref (which would be pretty surprising tbh) or whatever you want to call it to the one non-1-ZST¹ field of a repr(transparent) type.

However, this is kind of difficult (if not impossible?) in general. A repr(transparent) type can have more than one field: It can have none or exactly one non-1-ZST type and arbitrarily many 1-ZST fields. With this information consider the following valid Rust code:

#[repr(transparent)]
struct Main {
    x: A, // 1-ZST
    y: B, // non-1-ZST
    z: C, // 1-ZST
}

impl std::ops::Deref for Main { type Target = B; fn deref(&self) -> &Self::Target { &self.y } }

struct A { field: () }
struct B { field: i32 }
struct C { field: () }

Now it's kind of hard to deduce which field type pick for offset_of!(Main, field) without looking at Deref.

Footnotes

1. 1-ZST: A zero-sized type with an alignment of one ↩

[fmease]

Hmm, let me amend my previous comment, I guess it wouldn't be super hard to implement since we calculate all non-trivial field types at some point, namely here:

https://github.com/rust-lang/rust//blob/405b22f1a3a39eef5f4698b3662097c8a4f6f5d0/compiler/rustc_hir_analysis/src/check/check.rs#L1138

We would need to store that somewhere and enrich it with some more information (right now it's just Spans, we need at least the DefId, too) and then refer back to it when resolving fields in offset_of.

[fmease]

My previous point still stands though: In my humble opinion, it would be unexpected, unintuitive and completely new behavior to “deref” to the one non-1-ZST type of a repr(transparent) type without involving Deref.