Veikka Tuominen
Veikka Tuominen
Looks like LLVM doesn't like us returning 800kb arrays, prefixing the `zeroes` call with `comptime` makes the issue go away.
> Got similar results (compile-time-wise & memory-wise) with this piece of code: That's because you're making a struct with over 2 million fields. Arrays are able to use an optimization...
One possible addition to this (or a separate proposal) I've thought about is to also add a `src: ?builtin.SourceLocation` parameter. That combined with a new `@calleeSrc` builtin that behaves like...
`src.line` is not comptime-known to avoid breaking incremental compilation https://github.com/ziglang/zig/pull/12016#issuecomment-1178092847
weak memcmp symbol from compiler_rt is not overridden when building Python 3.11.0 on Linux and MacOS
The aarch64 CI makes those tarballs automatically but it mysteriously died three days ago a65ba6c85a6c01aecf28e39ba6717fea15757521
I'm able to reproduce this (or something similar) with https://github.com/Vexu/bun/commit/94d54c3fd1743b8851aa1873aabacf0ce8064ff0 and running `make headers`.
Reduction: ```zig fn FnPtrStage2Wrap(comptime T: anytype) @TypeOf(&struct { const FnPtrType = T; pub const fn_ptr: FnPtrType = undefined; }.fn_ptr) { return &struct { const FnPtrType = T; pub const fn_ptr:...
~~This looks like the cause: https://github.com/ziglang/zig/blob/684264908e50bc8537fc10859e93ccdf8d94509e/src/Module.zig#L3868-L3872~~ I don't get the error in the issue but it is saying that `data_ptr` is pointing to uninitialized byte(s): ``` ==51599== Syscall param writev(vector[...])...
> * `zig_i64 const a0` - is `int64_t const` different from `int64_t`? I don't 100% remember the rules in C here `zig_i64` is `int64_t`: ```c // zig.h typedef uint8_t zig_u8;...
> Running `zig build test --zig-lib-dir lib` gives me an enormous amount of memory leak Known issue, build with llvm backend enabled so that the compiler uses `malloc`.