Back out the new `-build-only` for tests in favor of the more established `-build-mode:test`, but retain the new `-keep-test-executable` option and default cleanup of test executables.
* Emit label debug info w/o location
* Insert debug label call
* Slight refactor for later fix
* Improve debug labels for block statements
* Improve debug info with for loops
* Generate label lbBlocks w/ debug
* Lightly refactor lb_add_debug_label
* Revise comments, add null check assertion
* Use LLVM-C API for debug labels
* Prefer C DILabel API for POSIX, fallback to CPP
* Use version check for LLVM-C DILabel
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 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.
Jeroen van Rijn
Feoramund
gingerBill
Laytan Laats
tf2spi
0xrsp
gingerBill
Lucas Perlind
bogwi
Barinzaya