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.
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.
Laytan Laats
gingerBill
gingerBill
Lucas Perlind
Jeroen van Rijn
Brian
Barinzaya
bogwi
Vincent Billet
Harold Brenes