Host Pointer Size Not Exposed At Comptime

[nsmryan]

Zig Version

0.10.0-dev.4707+209a0d2a8

Steps to Reproduce and Observed Behavior

Pointers to fields within a packed struct have a field bit-width in bits and a 'pointer host size' (size of the backing integer in bytes) attached to them that are not part of normal pointers.

This information can be provided when creating a pointer through the 'align' keyword, as in the following program which creates a pointer to a field in a packed struct and prints out the information about the pointer that is available through '@typeinfo':

const std = @import("std");

const S = packed struct {
    a: u4,
    b: u4,
};

pub fn main() void {
    var s: S = S{ .a = 1, .b = 2 };

    // First entry: alignment in bytes.
    // Second entry: size of the field itself in bits.
    // Third entry: size of the backing integer in bytes.
    const ptr: *align(1:2:1) u2 = @ptrCast(*align(1:2:1) u2, &s.b);

    std.debug.print("@typeInfo(ptr) = {}\n", .{@typeInfo(@TypeOf(ptr))});
}

However, once the pointer has been created there is no way to retrieve this information. It is not exposed through std.builtin.Type.

I believe that field width could be determined from std.builtin.Type.Pointer.child using '@bitSizeOf' (perhaps I'm missing a detail there), but the 'host pointer size' is not available.

Without this information, I cannot extract and store this information to later re-synthesize the pointer if it points within a packed struct.

Expected Behavior

I expect to be able to retrieve all information about a pointer using '@typeinfo' including the 'host pointer size'.

More generally: I expect that a pointer can be mapped to a std.builtin.Type structure and back without loss of information.

[rohlem]

Duplicate of #6846 iiuc. (This one has more text, so I guess we can close the old one if you want.)

[nsmryan]

I didn't see that issue. It does seem like the same concept, although I appreciate the point that it makes that perhaps Pointer.alignment is where the information is missing.

#6846 has a later milestone currently, so I favor #14568 :)