Evan Haas

The problem is that the compilation's built-in size type (`size_t`) was never generated, because you need to generate it via `comp.generateBuiltinMacros`. I can see how it's confusing since Compilation and...

It looks like the `alignof` function in `Type.zig` is returning the wrong value - it returns `8` for everything except `msp430` (should be `4` for `i386`). From a quick glance...

Depending on how it's lowered, that definition (where negative divisors are allowed) could lead to undefined behavior if the dividend is a signed int with the minimum value for the...

This is due to the switch to clang 15 for Zig 0.10.0, since support for old-style (K&R) function declarations is being removed: https://discourse.llvm.org/t/rfc-enabling-wstrict-prototypes-by-default-in-c/60521 You can manually disable it with `-Wno-deprecated-non-prototype`,...

I like this proposal and have often wanted this exact thing - ("release a release-fast build for the speed but keep certain less expensive runtime safety checks enabled like reached...

Superseded by #364 - @tomc1998 can you see if `netinet/in.h` parses correctly for you now?

Does the suggested fix in the comment here: https://github.com/ziglang/zig/issues/10793#issuecomment-1030504654= fix the issue?

I can confirm that the bug happens on MacOS using `Apple clang version 15.0.0 (clang-1500.3.9.4)` if `-O2` is used, and does not occur if `-O0` is used. This is either...

Here is a screen recording of myself compiling it with Apple system clang and reproducing the bug. https://github.com/ziglang/zig/assets/4575/7de29a2e-0e0c-4158-9105-62ff7136765e The warning about unsequenced modifications to `nNum2` may be relevant.

> This fix adds c_ulonglong to the list of signed candidate types. This seems to be at odds with C std 6.4.4.1p5 which, for instance, requires the extension type to...