Started with trying to enable asan in the CI for MacOS, noticed it wasn't enabled on the `tests/internal`
folder, it came up with a couple of issues with the abi/OdinLLVMBuildTransmute that this also solves.
- Looking at clang output for arm64, we should be promoting `{ i64, i32 }` to `{ i64, i64 }`
- after doing the previous point, I noticed this is not handled well in OdinLLVMBuildTransmute
which was emitting loads and stores into the space of a value that was alignment, asan does not want this,
looking at clang output again, a memcpy is the appropriate way of handling this.
- Having done this we don't need the hacky "return is packed" set anymore in the amd64 sysv ABI anymore either
Fixes#5128
p->builder is created in lb_begin_procedure_body, but that isn't called
if there is no body, and we were still calling dispose at that point.
Moved it into lb_end_procedure_body to match.
The _set_env procedure in core/os/os2/env_posix.odin was
incorrectly cloning the 'key' argument for 'cval' instead of
the 'value' argument. This resulted in set_env effectively
setting the environment variable's value to its own key.
This commit corrects the typo to use the 'value' argument.
The new reduce_add/reduce_mul procs perform the corresponding arithmetic
reduction in different orders than sequential order. These alternative
orders can often offer better SIMD hardware utilization.
Two different orders are added: pair-wise (operating on pairs of
adjacent elements) or bisection-wise (operating element-wise on the
first and last N/2 elements of the vector).
The original errors:
1. `5024.odin(127:15) Error: Invalid use of a polymorphic type 'List($T)' in variable declaration`
2. `5024.odin(129:17) Error: Cannot determine polymorphic type from parameter: 'invalid type' to 'List($T)'`
Are gone. We now have a single, different error:
`5024.odin(124:28) Error: Unspecialized polymorphic types are not allowed in procedure parameters, got List($T)`
This error points directly to the `list : List($T)` parameter within the `List_Filter` procedure definition. This seems much more relevant to the actual problem (the interaction between the generic `List_Filter` and the concrete `default_filter`) than the original error about the variable declaration.
While this new error message might not be exactly pinpointing the default parameter issue, it correctly identifies the problematic procedure definition (`List_Filter`) as the source of the error, rather than the variable declaration (`my_list`). This seems like a step in the right direction for improving the error reporting for this kind of scenario.
Laytan Laats
gingerBill
gingerBill
Lucas Perlind
Jeroen van Rijn
Brian
Barinzaya
bogwi
Vincent Billet
Harold Brenes