make `@offsetOf` runtime-known for types without well defined memory layout

[andrewrk]

test {
    const S = struct {a: i32, b: i32};
    _ = comptime @offsetOf(S, "b"); // error: unable to resolve comptime value
}

This is marked accepted, because at least one of the two things will happen:

• Trying to observe the memory layout of a non-well-defined-memory-layout will be a compile error
• Observing the memory layout of a non-well-defined-memory-layout will give a runtime value

Currently this is marked as accepted with the latter.

[andrewrk]

@fieldParentPtr is still planned to work fine for types without well-defined memory layout. @marler8997 pointed out this allows implementation of offsetof in userland, at runtime, by inspecting pointer addresses.

#7888 proposes to make offset-of always happen at runtime, but that's not correct for types with well-defined memory layouts.

This issue is amended to have offset-of return compile-time value for well-defined memory layout types, and runtime value for non-well-defined memory layout types. This gives compiler implementations the ability to delay field layout until the end of compilation.

[N00byEdge]

So saying "I don't care about the memory layout of this struct, but please give me the offset of this member for my inline assembly" isn't a supported use case anymore?

[marler8997]

@N00byEdge I think you could solve that by marking the struct as extern and/or packed. However, this use case and the proposal brings to light a now missing feature. When a user needs to know the layout of a struct at comptime, but they don't need it to be C abi compatible nor packed.

[andrewrk]

However, this use case brings and the proposal brings to light a now missing feature. When a user needs to know the layout of a struct at comptime, but they don't need it to be C abi compatible nor packed.

this issue remains open for that use case: #6700 (comment)

[N00byEdge]

Okay, so will this be blocked by that then? So that we always have a way to do this in the meantime?

[andrewrk]

Your inline assembly has to run at runtime anyway, so this issue does not affect this use case. If you have existing code that passes the result of @byteOffsetOf to inline asm it will continue working the same.

[N00byEdge]

No, this specific offset value is used as an immediate in an instruction, as I cannot clobber any registers at that point. https://github.com/FlorenceOS/Florence/blob/master/src/platform/aarch64/interrupts.zig#L152-L190

[andrewrk]

Thanks for bringing up specific code so we can talk about a concrete example. Even when using the "i" constraint for assembly, although the value must be known in the machine code generation phase of the compiler, it does not need to be known in a comptime sense. This is similar to the address of globals in that they are technically known by the compiler at compile-time however they are not available to, e.g. Zig code running in a comptime block.

We may want to introduce the concept of "late-stage constant values" in the documentation to represent this conceptually.

Regardless of what happens I will check with you before merging a change that could possibly break FlorenceOS, to make sure your use case is still handled properly. Similarly please do reach out if a different master branch commit breaks your workflow and let's make sure there is a clear path forward for your use cases.