Apple's lldb includes Swift, and `SBTarget.GetBasicType` may answer
from Swift's type system, such as `Swift.Int64` for `long long`. A
value made from such a type is empty, so in about half of all lldb
sessions an `any` holding a basic type, or a pointer or an array of
one, showed only the name of its type. Ask the `any`'s own type for
basic types instead, as it comes from the type system of Odin's
debug info.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Map keys of type `string16` used `default_hasher_string`, which reads
the length as a byte count; for a `string16` it counts u16 units, so
only the first half of the key was hashed. `cstring16` keys took the
same path and were read as a pointer and a length, which crashes.
Add `default_hasher_string16` and `default_hasher_cstring16` to the
runtime and use them for the generated key hashers, which are also
what the runtime and `intrinsics.type_hasher_proc` use.
An `any` holding a pointer, multi-pointer or fixed array printed raw,
as `{data = ..., id = ^int}`, since no debug type is named `^int` or
`[3]f32`. Build such types from their element, found by the rest of
the name, in both the gdb and lldb printers.
A non-nil `Maybe(^T)` or a #shared_nil union of pointers printed as
nothing, as gdb prints nothing for a pointer gdb.Value returned by a
printer's to_string. Return the pointer formatted as a string instead,
which is what the lldb summary already shows.
When a `context` is available, the `with_context` variant will be called
and the `context.assertion_failure_proc` will be called, instead of
forcibly trapping. This allows bounds check errors able to be handled by
custom assertion failure procs.
`base/runtime`: do not free the original block on a failed heap resize
The default heap allocator freed old_ptr when the underlying allocation
failed (allocated_mem == nil). On the realloc path (heap_resize) the original
block is left intact on failure, and on the copy/fresh path old_ptr has not
been copied or freed yet, so freeing it left the caller holding a dangling
pointer. A [dynamic] array whose resize failed therefore double-freed its
data on the next delete (reported as free(): invalid pointer / use-after-free).
Return .Out_Of_Memory without freeing anything; the caller retains ownership
of the original block.
Fixes#7262
The runtime implementations of quaternion division are incorrect when
calculating q/r with nonzero jmag(r) and either nonzero imag(q) or
kmag(q). Notably, the inverse 1/r is still calculated correctly
because imag(1) = kmag(1) = 0.
The mistake can be verified by calculating (a/b)*b which will be very
different from both a and a * (1/b) * b.
The compile-time constant folding is correct, see exact_value.cpp
in function exact_binary_operator_value -> ExactValue_Quaternion ->
Token_Quo.
quo256 :: proc(q, r: quaternion256) -> quaternion256 { return q/r }
a: quaternion256 : 3 + 5i + 7j + 11k
b: quaternion256 : 2 + 7i + 3j + 5k
c: quaternion256 : a/b
fmt.println("comp", abs((c*b) - a))
fmt.println("run ", abs(quo256(a,b)*b - a))
// both values should be very close to zero;
// without fix, only the first is
gingerBill