<div dir="ltr">Hmm - I didn't realize there was DWARF for describing defaulted operations. It looks like maybe this ended up in as a half fix to the issue of calling conventions (we had a few discussions with DWARF folks about whether knowing which ops were defaulted would be enough to know whether a class was to be passed by value or by reference in the calling convention - and eventually managed to demonstrate that it couldn't be and it would be best if DWARF encoded the decision, rather than the data for the decision - which is how we got DW_AT_calling_convention on types).<br><br>What's the motivation for implementing/emitting this DWARF? Are there any consumers or use cases you have in mind?<br><br>Anyway, let's see what the problem with the code is... looks pretty reasonable.<br><br>Might be easier with a test case/patch - perhaps you could post to Phabricator. <br><br>Though I don't see anything immediately wrong, it might be simpler/more efficient to use "getDefinition" to determine if the function is defined - rather than separately calling isDefined+getDefinition later. Call getDefinition and check if it's non-null:<br><br> else if (DXXC->isDefined()) {<br>  if (DXXC->getDefinition()->isDefaulted())<br>    SPFlags |= llvm::DISubprogram::SPFlagDefaultedOutOfClass;<br>  else<br>    SPFlags |= llvm::DISubprogram::SPFlagNotDefaulted;<br><br>-><br><br>if (const auto *Def = DXXC->getDefinition())<br>  if (Def->isDefaulted()<br>    ...<br>  else<br>    ...</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Sep 20, 2019 at 5:04 AM Sourabh Singh Tomar via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi All,<div><br></div><div>We're working DWARF-5 support in clang, c++11 Defaulted, deleted member functions. </div><div>We're facing an issue while parsing attributes of a destructor which is defined out of class. as default.</div><div>as in</div><div>class foo {</div><div>      public;</div><div>           foo();</div><div>           ~foo();</div><div>};</div><div>foo::foo() = default;</div><div>foo::~foo() = default;</div><div><br></div><div>Here's the code snippet of clang changes--</div><div><br></div><div>if (const auto *DXXC = dyn_cast<CXXDestructorDecl>(Method)) {<br>1624       if (DXXC->getCanonicalDecl()->isDeleted())<br>1625         SPFlags |= llvm::DISubprogram::SPFlagDeleted;<br>1626<br>1627       if (DXXC->getCanonicalDecl()->isDefaulted())<br>1628         SPFlags |= llvm::DISubprogram::SPFlagDefaultedInClass;<br>1629       else if (DXXC->isDefined()) {<br>1630         if (DXXC->getDefinition()->isDefaulted()) {<br>1631           SPFlags |= llvm::DISubprogram::SPFlagDefaultedOutOfClass;<br>1632         }<br>1633         else {<br>1634           SPFlags |= llvm::DISubprogram::SPFlagNotDefaulted;<br>1635         }<br>1636       }<br>1637     }<br></div><div><br></div><div>For, out of class  destructor definition defaulted, as mentioned above. We're not able get 

SPFlagDefaultedOutOfClass or 

SPFlagNotDefaulted.</div><div><br></div><div>seems like their is no definition of destructor, even when, we are defining them out of class as default; ??</div><div>  1629       else if (DXXC->isDefined())  -- evaluates as false <br></div><div><br></div><div>On the other side, If we declare our destructor as virtual, then above checks passes gracefully -- suggesting clang created a non-trivial destructor definition. </div><div><br></div><div>Is this behavior okay  ?? , -- this behavior is also prevalent in copy/move constructor and assignments. </div><div><br></div><div>Note-- For Constructor out of class definition as default -- clang create non-trivial constructor definition, and above check passes and we're are able to check capture the information about, whether the constructor is defaulted in class or out of class.</div><div><br></div><div>Any thoughts, greatly appreciated.</div><div><br></div><div>Thanks!</div><div>Sourabh Singh Tomar</div></div>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
</blockquote></div>