An `any` holding a named type, such as `main::Point`, showed only the
name of its type in lldb. `FindTypes` reads `main::Point` as `Point`
in a namespace `main`, but Odin's DWARF names the type `main::Point`
with no namespace, so the lookup found nothing. When `FindTypes` finds
nothing, look the name up in an index of each module's types, made
once per module.
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>
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.
BB