[PATCH] D75585: Add debug info support for Swift/Clang APINotes.

[David Blaikie via Phabricator via llvm-commits]

dblaikie added a comment.

>>> In order for dsymutil to collect .apinotes files (which capture attributes such as nullability, Swift import names, and availability), I want to propose adding an apinotes: field to DIModule that gets translated into a DW_AT_LLVM_apinotes (path) nested inside DW_TAG_module. This will be primarily used by LLDB to indirectly extract the Swift names of Clang declarations that were deserialized from DWARF.
>> 
>> & this applies not just to dsymutil, right? Presumably it's used by debuggers when debugging using unlinked debug info, or using non-.o+dsymutil style debug info, such as when using Swift on Linux/ELF?
> 
> Absolutely. The end goal is for LLDB to import the APINotes, so it can access the attributes. What I'm particularly interested in right now is the Swift name attribute, which defines the name under which an (Objective-)C declaration should be imported into Swift, so LLDB can import Clang types from DWARF into Swift under the correct name.
> 
>> Is it worth discussing whether these apinotes should be embedded directly into the debug info, rather than referenced by file name? I guess they're /sort/ of like source files (they likely have the same distribution model - so if the source is accessible, so are the apinotes), so referencing by file name makes sense?
> 
> The alternative I considered was to invent explicit DWARF for all of the attribute kinds and put them on the decl in CGDebugInfo and deserialize them in LLDB and put them as attributes on the Decl. However, compared to just passing the apinotes file verbatim to Swift's ClangImporter this would be a lot more churn in upstream LLVM, as we'd need to add several new attributes to almost every type and decl kind.

oh, yeah, I wasn't thinking that level of fidelity - just the whole file embedded as a string or something. But yeah, doesn't seem like that'd be especially better. If APINotes is like a source/header file type thing (some could be user authored, others could be generated from something else, same way header/source might be generated) then it seems fine to reference it on disk.

I guess the only thing that makes me vascillate a bit is that debuggers don't usually process the source in any way - they just render it to the user. APINotes are meant to be semantically consumed by the debugger - that's where the analogy breaks down a bit for me, but not necessarily in a way that invalidates this approach. APINotes seem to be much more readily machine readable (JSon, etc) than, say, C++ source (reason debuggers don't just reparse the source to get type information, etc).


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D75585/new/

https://reviews.llvm.org/D75585