Build.zig: create: debug_stack_frames_count is uninitialized

[CorruptedVor]

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.

[CorruptedVor]

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 ?

[CorruptedVor]

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