Joseph Ferano
3b8a0cb553
Every Tast node carries a Loc and nothing ever used one outside an error message, so a Flan program under a debugger was a wall of addresses. This emits DWARF for them. The reason it is a few hundred lines and not a few thousand is the layout. A Flan struct is its C struct, every slot is an alloca and there are no tag words, so there is nothing to describe *about Flan* — DW_LANG_C99 and the machine types are the honest answer, and lldb's own C support is then exactly right for a Flan value. Two things are load-bearing and neither is obvious: Debug Info Version in llvm.module.flags. Without it LLVM drops every scrap of debug metadata with no diagnostic at all, so the build succeeds and the debugger shows nothing and there is no thread to pull. A !dbg on every instruction, not only the ones that want a line. The verifier rejects a call without a location inside a function that has debug info, and this file emits calls from a dozen places — the bounds failure, the handler push and pop, the transfer guards — none of which would have remembered to ask. So the location lives on the per-function state and `ins` appends it. The member offsets are computed here rather than handed to LLVM, which is the one place in this backend that happens and so the one place a layout bug can hide. !DIDerivedType takes offset: as an integer literal; the ptrtoint-of-gep form this file uses elsewhere for a size is not accepted in metadata. The acceptance test therefore checks each one against LLVM's own getelementptr answer for the same struct type, not against a table written by the same hand. Local names are the gap. The typed IR refers to slots by index and records no names — Check has them and drops them — so a parameter gets its source name, recovered by the driver from declarations already in hand, and everything else gets s<index>, which is the slot it actually is. Closing that means Tast carrying the name.
