* 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.
Enhance support for polymorphic procedures in type checking
1. In src/check_type.cpp, added special handling for polymorphic procedures used as default parameter values. We now allow a polymorphic procedure to be used as a default parameter value, even when its type parameters can't be immediately determined.
2. In src/check_expr.cpp, we modified the check_is_assignable_to_with_score function to handle the special case of assigning a polymorphic procedure as a default parameter. The function now allows a polymorphic procedure to be assigned to a concrete procedure type in this specific context.
Add support for handling generic types in LLVM backend
- Updated `lb_type_internal` to return a pointer type for unspecialized generics.
- Modified `write_type_to_canonical_string` to handle specialized generics without panicking.
- Enhanced `default_type` to return the default type of specialized generics when applicable.
Fix panic in LLVM backend when using generic procedure with default arguments
- Fixed panic in `llvm_backend_proc.cpp` when using unspecialized polymorphic procedures as defaults.
- Ensured correct type inference when generic procedures are used as default parameters.
Previously, it implied that these are different types:
```
W:/Scratch/scratch.odin(17:5) Error: Cannot compare expression, operator '==' not defined between the types 'Handle_Map($T=u32, $HT=u32, $Max=10000)' and 'Handle_Map($T=u32, $HT=u32, $Max=10000)'
if m == {} {
^~~~~~^
```
Now:
```
W:/Scratch/scratch.odin(20:5) Error: Cannot compare expression. Type 'Handle_Map($T=u32, $HT=u32, $Max=10000)' is not simply comparable, so operator '==' is not defined for it.
if m == {} {
^~~~~~^
```
