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.
The purposes of this attribute is to let procedures opt-out of being
instrumented with asan. Typically an allocator that includes 'in-band'
meta-data will be accessing poisoned values (such as tlsf).
Making asan work with these allocators becomes very challenging so
just being to ignore asan within specific allocator procedures
makes it easier to reason and removes the need to temporarily
poison and unpoison allocator data.
It's a bit of a band aid fix because the field will get the type of the
alias, not the base type, but that was already the case before #5045 so
it's forward progression.
Closes#5092Fixes#5061
The initial allocation for the slice is limited to prevent untrusted
data from forcing a huge allocation, but then the dynamic array was
created with a capacity of the unlimited length, rather than the actual
capacity of the allocation. This was causing a buffer overrun.
blob1807
Jeroen van Rijn
omark96
Barinzaya
Harold Brenes
gingerBill
jason
Lucas Perlind
Rohan Jadav
Laytan
Vincent Billet
Jamie Dennis
Michael Lee
gingerBill