[PATCH] D109970: [DebugInfo] Support DW_AT_defaulted

[David Blaikie via Phabricator via llvm-commits]

dblaikie added a comment.

Any particular use case in mind for this debug info? (generally I'd rather we not emit extra DWARF we don't have some use case for in mind)

(& if/when this is committed, should be in 3 parts - dwarfdump support, IR/codegen support (can be split into two if you like, but doesn't have to be), and Clang support)



================
Comment at: clang/lib/CodeGen/CGDebugInfo.cpp:1792-1811
+  // We're checking for deleted/defaulted C++ special member functions
+  // [Ctors, Dtors, Copy/Move].
+  auto checkDeletedOrDefaulted = [&](const auto *Method) {
+    // '= delete' must be on the first declaration, so checking the
+    // canonical decl is sufficient.
+    if (Method->getCanonicalDecl()->isDeleted()) {
       SPFlags |= llvm::DISubprogram::SPFlagDeleted;
----------------
Looks like this'll do the right thing, but probably want to make sure there's a test case for "deleted as default".

something like:
```
struct t1 {
t1() = delete;
};
struct t2 {
  t1 v1;
  t2() = default; // this is deleted
};
```

at least I /think/ that'd tickle the case.


================
Comment at: llvm/lib/IR/DebugInfoMetadata.cpp:854-855
+  // Multi-bit fields can require special handling. In our case, there
+  // are two: DeletedOrDefaulted, and Virtuality.  We special-case one
+  // value for DeletedOrDefaulted, but everything else happens to have
   // single-bit values, so the right behavior just falls out.
----------------
How does Virtuality work? Can we avoid the special case for DefaultedOrDeleted in the same way that it is avoided for Virtuality?


================
Comment at: llvm/test/DebugInfo/X86/DW_AT_defaulted.s:1
+## Demonstrate dumping DW_AT_defaulted.
+## Any ELF-target triple will work.
----------------
I'd tend to put pure dwarfdump tests in llvm/test/tools/llvm-dwarfdump (but I get that it's all a bit mixed/ambiguous - I know you mentioned a while back about the idea of keeping test/DebugInfo for the actual libDebugInfo tests, but it'd sort of already sailed/had lots of LLVM codegen tests in there - and equally in theory llvm/test/tools/llvm-dwarfdump could be just for tests of llvm-dwarfdump.cpp and related files, not the library implementation... ) ah well. Just a thought.


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

https://reviews.llvm.org/D109970