No idea why the floattidf procs are bodged to return 0, does somebody
know? I have just enabled the original codepath, if nobody knows I
suggest just enabling it and see if we get complaints, it works on all
wasm stuff I tried.
The linkage being set to "internal" instead of "strong" is actually
causing problems in my projects which is what prompted looking at this
in the first place, some of these functions were actually needed but not
added/used because they had internal linkage. This only happens on
bigger projects (or just when using f16?).
Unfortunately `git blame` gave me this generic commit: https://github.com/odin-lang/Odin/commit/94bad4d7861c78b9e7191ec0c3114861a1536d5c#diff-fb9f42022cb95efa59d16813546b8cb310234428c85edfabf09b1425c9dc46af
Before this if you do `arr: [dynamic]int` and then append to arr, then it will have capacity 8.
But if you did `arr := make([dynamic]int, context.temp_allocator)` then arr would have capacity 16.
Now both `arr: [dynamic]int` and `arr := make([dynamic]int, context.temp_allocator)` will resut in arr having zero 0. The only reason to use `make` without an explicit len or cap now is because you want to set it up for a non-default allocator. After the first call to `append` it will now in both cases have capacity 8.
I also updated the documentation on the strings builder, both to reflect this, and also to fix it incorrectly saying that len would be 'max(16,len)', which wasn't true even before these changes.
`ODIN_VERSION_HASH` is the `git` SHA hash of the commit the Odin
compiler was built with.
`ODIN_MICROARCH_STRING` is the string passed to `-microarch` when
the program was built.
`ODIN_OPTIMIZATION_MODE` is an enum value of which optimization mode was
used to build the program.
Laytan Laats
gingerBill
Damian Tarnawski
Jeroen van Rijn
Karl Zylinski
gingerBill
Feoramund