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.
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 == {} {
^~~~~~^
```
The indices proc simply creates a vector where each lane contains its
own lane index. This can be useful for use in generating masks for loads
and stores at the beginning/end of slices, among other things.
The new reduce_add/reduce_mul procs perform the corresponding arithmetic
reduction, in different orders than just "in sequential order". These
alternative orders can often be faster to calculate, as they can offer
better SIMD hardware utilization.
Two different orders are added for these: pair-wise (operating on
adjacent pairs of elements) or split-wise (operating element-wise on the
two halves of the vector).
This doesn't actually cover the *fastest* way for arbitrarily-sized
vectors. That would be an ordered reduction across the native vector
width, then reducing the resulting vector to a scalar in an appropriate
parallel fashion. I'd created an implementation of that, but it required
multiple procs and a fair bit more trickery than I was comfortable with
submitting to `core`, so it's not included yet. Maybe in the future.
