`rawptr` pointed to a 1-byte `void` base type, so gdb printed every
rawptr, such as an allocator's `data`, as a C string. Describe it as a
pointer with no pointee type, which is how clang emits `void *`. This
also drops the address space it was given by mistake.
The name `cstring16` was passed with the length of `cstring`, so the
type was named `cstring`. Its characters, and those of `string16`,
were a 16-bit `wchar_t`, which gdb reads as UTF-32 on Linux and so
printed as garbage. On DWARF describe them as `char16_t`, a 16-bit UTF
character, which gdb reads as UTF-16. CodeView keeps `wchar_t`.
With the split debug types modules, every other module only declares a
record type. gdb resolves a declared struct by searching for its
definition, but a declared enum by taking the first symbol of that name,
which is the declaration itself in the module being looked at. Enums,
flag enum bit_sets and typeid showed as <incomplete type>, and every
`any` printed as nil since its `id` could not be read. gdb also cannot
find a declared type whose name starts with `#`, so #soa types were
incomplete too.
On DWARF, define these in every module that uses them, as clang does
with enums. CodeView resolves forward references by name, so Windows
keeps them in the types modules.
* Emit label debug info w/o location
* Insert debug label call
* Slight refactor for later fix
* Improve debug labels for block statements
* Improve debug info with for loops
* Generate label lbBlocks w/ debug
* Lightly refactor lb_add_debug_label
* Revise comments, add null check assertion
* Use LLVM-C API for debug labels
* Prefer C DILabel API for POSIX, fallback to CPP
* Use version check for LLVM-C DILabel
This fixes (on my end) #3340, #3117, #2945, #2922, and #2762
A general refactor of debug info generation in order to fix issues and
increase stability.
What I believe is the root cause of a bunch of issues is that we use the
temporary metadata/forward declarations too much (/ hold onto them for
too long). It seems to cause problems with the reference counting inside
LLVM.
This PR reduces the use of these forward declarations to a minimum, it
creates it, fills in the fields, and resolves it, instead of waiting
until the end of generating code.
Some smaller issues I came across have also been solved.
bbodi