std.os.linux.perf_event_attr triggers compile error due to missing backing int for packed struct #31465

Zig Version

0.16.0-dev.2821+3edaef9e0

Steps to Reproduce and Observed Behavior

I think this is a direct consequence of the awesome work done in #31403. Now, Packed structs without an explicit backing integer type can't be used as fields in extern structs/unions. This breaks std.os.linux.perf_event_attr:

conststd=@import("std");constlinux=std.os.linux;pubfnmain()void{varattr=linux.perf_event_attr{.type=.HARDWARE,.config=@intFromEnum(linux.PERF.COUNT.HW.INSTRUCTIONS),.flags=.{.disabled=true,.exclude_kernel=true,.exclude_hv=true,.inherit=true,.enable_on_exec=true,},};_=linux.perf_event_open(&attr,0,-1,-1,linux.PERF.FLAG.FD_CLOEXEC,);}

with the error:

/home/phugen/.zv/versions/master/0.16.0-dev.2821+3edaef9e0/lib/std/os/linux.zig:9518:19: error: extern structs cannot contain fields of type 'os.linux.perf_event_attr__struct_32488'
 flags: packed struct {
 ~~~~~~~^~~~~~
/home/phugen/.zv/versions/master/0.16.0-dev.2821+3edaef9e0/lib/std/os/linux.zig:9518:19: note: inferred backing integer of packed struct has unspecified signedness
/home/phugen/.zv/versions/master/0.16.0-dev.2821+3edaef9e0/lib/std/os/linux.zig:9518:19: note: struct declared here
referenced by:
 main: repro.zig:6:18
 callMain [inlined]: /home/phugen/.zv/versions/master/0.16.0-dev.2821+3edaef9e0/lib/std/start.zig:677:59
 callMainWithArgs [inlined]: /home/phugen/.zv/versions/master/0.16.0-dev.2821+3edaef9e0/lib/std/start.zig:629:20
 posixCallMainAndExit: /home/phugen/.zv/versions/master/0.16.0-dev.2821+3edaef9e0/lib/std/start.zig:582:38
 2 reference(s) hidden; use '-freference-trace=6' to see all references

Expected Behavior

std.os.linux.perf_event_attr and other types that use packed structs inside extern types in the stdlib should be usable

I'm not totally sure if that is a regression on packed structs backing integers inference or it is part of the type resolution rework and it just happened to forgot to update the cases in the stdlib.

The Zig langref says:

All packed structs have a backing integer, which is implicitly
determined by the total bit count of fields, or explicitly specified.
[...] When inferred, it will be unsigned.
— langref §packed struct

And for extern structs:

An extern struct has in-memory layout matching the C ABI for the target.
— langref §extern struct

There is no documented restriction against packed structs with inferred
backing types inside extern structs — only that the resulting memory
layout must be C-compatible.

From my research this was introduced in
b19074d252. Before that commit, validateExtern in src/Type.zig just checked the resolved backing integer type — it didn't care
if it was user-provided or inferred. This worked fine because the compiler always resolves the backing type during layout resolution:

After, validateExtern was rewritten to switch on packed_backing_mode:

This rejects .auto unconditionally, even though packed_backing_int_type is already resolved and valid. From my user
understanding packed struct(u64) or packed struct (with u64 equivalent of data) should be equivalent.

I'm not sure how to proceed, If this is accepted behaviour, I've prepared a patch in https://codeberg.org/Tomcat-42/zig/src/branch/fix/perf-event-attr-packed-struct for fixing the cases that this happens in the stdlib + improving a little the error message. But if that is a regression, maybe we can always validate the resolved backing integer type? smth like this:

// src/Type.zig validateExtern().@"packed"=>Type.fromInterned(struct_obj.packed_backing_int_type).validateExtern(...),

Sorry if mentioning core members in issues is considered rude, but maybe @mlugg can find this interesting.

I think this is intentional, so labeling as an std bug for now. @mlugg can correct if I'm wrong.

Compiler is indeed working as intended: this is https://github.com/ziglang/zig/issues/24714. I would argue that the error message even explains exactly why that restriction exists in fact:

note: inferred backing integer of packed struct has unspecified signedness

(so yes, this is an std bug)

Thanks @mlugg, I missed the original proposal in my search, now it makes so much sense.

I've opened #31482