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

Wed Mar 4 10:07:08 PST 2020

dblaikie added a comment.

> Disclaimer: This is a little awkward, since this adds DWARF support for a feature that is currently only present in swift-clang but has been proposed for upstreaming (http://lists.llvm.org/pipermail/cfe-dev/2015-December/046335.html) multiple times (http://lists.llvm.org/pipermail/cfe-dev/2017-May/053860.html) and will — I believe — eventually find tis way into upstream clang.

Those threads are fairly old (2015 and 2017 respectively). If this is a relevant goal/justiifcation, perhaps it should be moved forward a bit more along with this proposal. Though I'm not 100% sure it's necessary for this feature to be used in clang for it to be added to LLVM - Julia and other non-clang/non-llvm-project frontends have, to my knowledge, had features added to upstream LLVM for their use cases that were never generated by any frontend in llvm-project. (stackmap/patchpoint comes to mind?)

Just to clarify the purpose of the feature in this thread/review: apinotes allow externally imposing attributes on functions/entities you don't own, right? (sort of the same reason as ADL in C++ - I want to say something about "swap" but I don't own the canonical swap, so I need some mechanism to do that)

> 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?

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?

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

https://reviews.llvm.org/D75585