Zig tracking issue

[IntegratedQuantum]

This tracking issue is for contributors of the Zig language so they can assess which issues are relevant for zig projects
(for more info: https://github.com/ziglang/zig/wiki/Third-Party-Tracking-Issues-(what-is-important-to-other-people%3F))

Major Problems

Compiler Bugs

• The most annoying thing is that zig sometimes crashes when it should report a compiler error, I think this started happening after the introduction of the InternPool. (these particular issues have been fixed, but I still got yet another instance of this error recently)
  Compiler fails to report compiler errors after update, assertion failure in debug builds. ziglang/zig#19514
  Crash in InternPool when referencing a non-existant member of a struct ziglang/zig#17878
  Crash in InternPool when faulty packed struct is inside an extern struct ziglang/zig#17859

• There appears to be a problem with the zig linker on macos, that makes development on macos more difficult:
  error.UnexpectedRemainder on aarch64 MacOS release targets ziglang/zig#17424

• Caching breaks frequently, making it recompile the game even though no source files changed:
  Zig sometimes produces a bad entry in the global cache that breaks caching entirely for my project (across all clones) ziglang/zig#23409

Stdlib Bugs

• The GeneralPurposeAllocator sometimes causes out of memory despite having enough system memory
  GeneralPurposeAllocator reports error.OutOfMemory despite having more than enough free memory. ziglang/zig#18775
  Internal Issue: out of memory error on linux when too many chunks are allocated. #182

Smaller Annoyances and Wishes

Compiler Bugs

• There are lots of memcpy operations when working with large arrays and structs. I often have to work around these manually by introducing additional address of operators before an array access. These issues are mostly harmless for me since I can easily work around them, but sometimes it catches me by surprise.
  Another array access performance issue. ziglang/zig#13938
  Still another array access performance issue (in debug) ziglang/zig#15685
• This is also was causing problems at some point and I have a todo about it in my code, again easy to work around:
  Regression with "Unable to evaluate constant expression" in len of fixed size arrays ziglang/zig#15280
• testing does not work with std.log.err. Internal issue: The problem of testing with std.log.err #1275,
  Zig issue: Integrate std.log with std.testing ziglang/zig#5738 (comment)

Performance Improvements

• Any compile-time improvements are much appreciated, especially incremental compilation.
  • Currently this fails due to Trying to compile Cubyz with .use_llvm = false produces panic: getOffset: [sym:3691 + 0x0] ziglang/zig#23143
• Improvements to the speed of debug builds would also be nice, Cubyz needs to generate a part of the world before I can interact with it, and reducing that time would increase iteration speed.
• I use the GeneralPurposeAllocator quite a lot in Cubyz, so an improvement in performance would be great there
  investigate SmpAllocator performance with respect to other popular allocators ziglang/zig#12484

Features

• I'm pretty unsatisfied with the current for loop, using while loops often pollutes the namespace. Most of these problems would be fixed if the for loop supported different number type. While Andrew said that there are some problems with the implementation, I think it would be useful to many people and it would be worth putting more effort into it.
  For loop range is unusable with types other than usize ziglang/zig#17039
  Proposal: Infer type on ranged for loops from the type of the range values instead of defaulting to usize ziglang/zig#14704
• I use vectors quite a lot and I sometimes require logical operations, such as element-wise and
  and cannot operate on vectors of bool despite the manual claiming otherwise ziglang/zig#14306