Unexpected error: duplicate struct field: '0' in translated C code

[artob]

The contents of the file duplicate-struct-field-0.zig:

const std = @import("std");
const testing = std.testing;

// zig translate-c api-level.h | head -n8 | pbcopy
pub export fn android_get_device_api_level() c_int {
    var value: [92]u8 = .{
        @bitCast(u8, @truncate(i8, @as(c_int, 0))),
    } ++ .{0} ** 91;
    if (__system_property_get("ro.build.version.sdk", value) < @as(c_int, 1)) return -@as(c_int, 1);
    var api_level: c_int = atoi(value);
    return if (api_level > @as(c_int, 0)) api_level else -@as(c_int, 1);
}

test "error: duplicate struct field: '0'" {
    testing.expect(android_get_device_api_level() == -1);
}

The contents of the file api-level.h:

int android_get_device_api_level() {
  char value[92] = { 0 };
  if (__system_property_get("ro.build.version.sdk", value) < 1) return -1;
  int api_level = atoi(value);
  return (api_level > 0) ? api_level : -1;
}

This is with HEAD built a few weeks ago (2e53425).

[artob]

Updated my Zig build to the latest HEAD (7ee0e77), and the translated code looks slightly different:

8,9c8,9
<     if (__system_property_get("ro.build.version.sdk", value) < @as(c_int, 1)) return -@as(c_int, 1);
<     var api_level: c_int = atoi(value);
---
>     if (__system_property_get("ro.build.version.sdk", &value) < @as(c_int, 1)) return -@as(c_int, 1);
>     var api_level: c_int = atoi(&value);

However, the exact same error nonetheless persists on zig test duplicate-struct-field-0.zig.

[LemonBoy]

Duplicate of #3882 and fixed in #4152 if I remember correctly.

[andrewrk]

After #4152, this gives me:

./test2.zig:6:26: error: use of undefined value here causes undefined behavior
    var value: [92]u8 = .{
                         ^
./test2.zig:8:7: note: referenced here
    } ++ [1]u8{0} ** 91;
      ^

Maybe that can be considered a separate bug, but let's focus here. The code that translate-c should generate is:

    var value: [92]u8 = [1]u8{
        @bitCast(u8, @truncate(i8, @as(c_int, 0))),
    } ++ [1]u8{0} ** 91;

...which compiles fine. So I'm labeling this a translate-c bug.