```
$ cat overflow.zig
test {
var a: [1]u65535 = undefined;
_ = a;
}
$ zig-out/bin/zig test overflow.zig
thread 290266 panic: integer overflow
zig/src/type.zig:3604:55: 0xada43d in intAbiAlignment (zig)
std.math.ceilPowerOfTwoPromote(u16, (bits + 7) / 8),
^
zig/src/type.zig:3598:42: 0xadd4ea in intAbiSize (zig)
const alignment = intAbiAlignment(bits, target);
^
zig/src/type.zig:3500:61: 0x92be91 in abiSizeAdvanced (zig)
return AbiSizeAdvanced{ .scalar = intAbiSize(bits, target) };
^
zig/src/type.zig:3385:62: 0x928933 in abiSizeAdvanced (zig)
switch (try payload.elem_type.abiSizeAdvanced(target, strat)) {
^
zig/src/type.zig:3268:32: 0x92c012 in abiSize (zig)
return (abiSizeAdvanced(ty, target, .eager) catch unreachable).scalar;
^
```
This is only noticed in a debug build of zig and silently does the wrong
thing and overflows in release builds.
This happened to `[x]u65529` and above because of the ` + 7` on a `u16`.
Fixes#15489
This also lays the groundwork for exposing the whether or not a function is
noinline in std.builtin.Fn as an `is_noinline: bool` field if we ever want to do that.
When the element is comptime-known, we can check if it has a repeated
byte representation. In this case, `@memset` can be lowered with the
LLVM intrinsic rather than with a loop.
On Windows, a directory that's set as the current working directory is
not allowed to be removed. This can cause error on `deleteTree` if the
CWD is set to the file to be removed and will cause `error.FileBusy`.
However, due to `tmp.cleanup()` ignoring the errors, the folder removal error will
be ignored. The only test violating this is `windows_spawn`. As a
solution, setting the parent directory to be the CWD before deletion
will allow the cleanup to pass.
This fixes a bug where resolveStructLayout to was promoting from stale
value_arena state which was then overwrriten when another ArenaAllocator
higher in the call stack saved its state back. This resulted in the memory
for struct_obj.optmized_order overlapping existing allocations.
My initial fix in c7067ef wasn't sufficient, as it only checked if the struct being
resolved had the same owner as the current sema instance. However, it's
possible for resolveStructLayout to be called when the sema instance
has a different owner, but the struct decl's value_arena is currently in
use higher up in the callstack.
This change introduces ValueArena, which holds the arena state as well as tracks
if an arena has already been promoted from it. This allows callers to use the
value_arena storage without needing to be aware of another user of this same storage
higher up in the call stack.
