Build.zig: create: debug_stack_frames_count is uninitialized

Zig Version

master (07e7cfa)

Steps to Reproduce and Observed Behavior

this is an issue because Build/Step.zig uses it to alloc something

zig/lib/std/Build/Step.zig

Line 224 in 07e7cfa

const addresses = arena.alloc(usize, options.owner.debug_stack_frames_count) catch @panic("OOM");

not initialized by this function:

zig/lib/std/Build.zig

Line 254 in b1a0a4e

pub fn create(

triggers valgrind warnings in the test suite:

 74 69/74 Build.Step.Options.decltest.Options...==13996== Conditional jump or move depends on uninitialised value(s)
 75 ==13996==    at 0x10C40CC: math.mul__anon_11976 (math.zig:562)
 76 ==13996==    by 0x112A9EC: mem.Allocator.allocWithSizeAndAlignment__anon_28635 (Allocator.zig:268)
 77 ==13996==    by 0x11D5797: allocAdvancedWithRetAddr (Allocator.zig:257)
 78 ==13996==    by 0x11D5797: mem.Allocator.alloc__anon_121063 (Allocator.zig:181)
 79 ==13996==    by 0x11B3ACD: Build.Step.init (Step.zig:224)
 80 ==13996==    by 0x11AF230: Build.create (Build.zig:290)
 81 ==13996==    by 0x11AC5EC: Build.Step.Options.decltest.Options (Options.zig:555)
 82 ==13996==    by 0x1115E8A: test_runner.mainTerminal (test_runner.zig:218)
 83 ==13996==    by 0x110FE81: test_runner.main (test_runner.zig:66)
 84 ==13996==    by 0x110F61D: callMain (start.zig:618)
 85 ==13996==    by 0x110F61D: callMainWithArgs (start.zig:587)
 86 ==13996==    by 0x110F61D: main (start.zig:602)

additional context: #24833 (comment)

Expected Behavior

debug_stack_frames_count is initialized, not triggering any valgrind warnings in the test suite

[rpkak]

Maybe it would make more sense to initialize struct fields, which are not explicitly set but have default values, at the beginning of the .{ [...] } expression, instead of at the end. This would fix this issue.

Maybe it would make more sense to initialize struct fields, which are not explicitly set but have default values, at the beginning of the .{ [...] } expression, instead of at the end. This would fix this issue.

something like this?
const f: Build = .{};
const b = try arena.create(Build);
b.* = f;
[... rest same as before]

[rpkak]

Maybe it would make more sense to initialize struct fields, which are not explicitly set but have default values, at the beginning of the .{ [...] } expression, instead of at the end. This would fix this issue.

something like this?
const f: Build = .{};
const b = try arena.create(Build);
b.* = f;
[... rest same as before]

I don't really understand what you want to highlight.

My Idea above is not specific to the problem in Build.create, but that in

const T = extern struct {
    a: u64 = 1,
    b: u64,
};

extern fn f(*T) u64;

export fn g(t: *T) void {
    t.* = .{
        .b = f(t),
    };
}

g should be more like

t.a = 1;
t.b = f(t);

instead of

t.b = f(t);
t.a = 1;

[mlugg]

Maybe it would make more sense to initialize struct fields, which are not explicitly set but have default values, at the beginning of the .{ [...] } expression, instead of at the end. This would fix this issue.

That would be a weird language hack to deal with this particular case, and would make this behaviour depend on RLS (result pointers). The correct fix here is straightforward: initialize the steps to undefined at first, and call Step.init only after assigning the rest of b.*.

[trebe]

Looks like this was fixed with PR #25227 ?

Nope, still reproducible (Build.Step.Options.decltest.Options test) with 12ed0ff