[PATCH] D68117: [DWARF-5] Support for C++11 defaulted, deleted member functions.

Tue Oct 15 17:26:52 PDT 2019

dblaikie added a comment.

In D68117#1709712 <https://reviews.llvm.org/D68117#1709712>, @probinson wrote:

> In D68117#1709557 <https://reviews.llvm.org/D68117#1709557>, @SouraVX wrote:
>
> > Their's not much information available behind the suggestion or intention for adding this feature to Spec. http://dwarfstd.org/ShowIssue.php?issue=141215.3  -- I think Paul can better provide remarks on this one.
>
>
> "It affects overload resolution" according to my record of the DWARF meeting where we discussed this.  Although "overload" resolution might not be the technically correct term.  Deleted is different from omitted, when trying to determine what to do with a particular source-language expression.

Carey's notes on the original give some idea: http://dwarfstd.org/ShowIssue.php?issue=141003.1 - with regards to the calling ABI. But Richard Smith explained that any solution like this would not be complete - and indeed, even in that issue the incompleteness is discussed and a second attribute DW_AT_layout to help address this and Carey filed another issue with a different proposed solution: http://dwarfstd.org/ShowIssue.php?issue=141215.1 that has some of the same phrasing and a different approach to address this, proposing a DW_AT_calling_convention attribute - this attribute was accepted.

So, by my reckoning, I don't know why the DW_AT_defaulted was kept/made it into the standard - it was an incomplete solution to the problem it was proposed to fix, and a complete solution was added as well.

(deleted is different - and while recording all deleted functions is probably impractical, though could benefit consumers (as could having all function overloads, and having raw template descriptions) - as without all the original code, overloads, and templates, expression evaluation will always be inaccurate (a consumer may choose overload candidates that the same expression in the original source would not have chosen - not just rejecting expressions that call functions that were not code generated), deleted special members are a bit special and may be useful to include to ensure the consumer doesn't attempt to synthesize trivial or default implementations)

>> GCC and GDB side of things-- I've checked GCC-9.2.0 implements this feature, but didn't noticed any use of this feature from GDB side{GDB.8.3}. It's merely declaration of the forms available. GCC's implementation  doesn't emit DW_DEFAULTED_no -- skipping DW_AT_defaulted attribute for that function. Current  GCC implementation addresses in_class, out_of_class attributes and of_course DW_AT_deleted.
>> 
>> Regarding my patch and whether we should add this in clang/llvm--
>>  Please correct me, in case I'm mistaken. David are you suggesting that, may be just "DW_DEFAULTED_yes"  can suffice our needs instead of using the Spec {in_class, out_of_class, DEFAULTED_no}. We could do that, that would incur mostly adding a custom "DW_DEFAULTED_yes" {non-conflicting to Spec} opcode in LLVM, Not sure about this to addition to LLVM ??. 
>>  Or we can choose same approach as GCC.
>>  Please share your thoughts on this. which direction should we choose ?? Or you guys have altogether something different in mind.
> 
> I don't see any problem with omitting the attribute instead of explicitly saying DEFAULTED_no.  There is no DW_DEFAULTED_yes, if we provide the attribute at all it would have to distinguish in-class vs out-of-class in order to conform.  I know the compiler does treat them a little differently depending on in-class vs out-of-class; if nothing else, in-class is inlined more aggressively and might not have an out-of-line instance at all.  This might matter to a debugger trying to support source-language expression evaluation.

Yes, sorry, my "DEFAULTED_yes" wasn't an attempt to propose a new DWARF feature, just ignorance having not recently read what the existing feature contains.

I think the existing feature's perhaps a bit misspecified - because where you put the DEFAULTED_{in_class,out_of_class} would communicate that without needing the two values - if you put it on an out of line function definition, it's defaulted out of line, if you put it on the in-class declaration then it's defaulted inline.

But spec'd the way it is, if we want to implement this at all/if there's some actual user need (admittedly the noreturn attribute has gone in recently without a discussion of usage... so I'm not the only gatekeeper here & other people have other opinions, and that's OK - if someone (@probinson @aprantl etc) want to tell me I'm being unreasonable here & we should just put it in - it's only a bit here or there & not likely to make a huge difference to DWARF size & possibly enable some scenarios we haven't imagined yet and avoid the chicken-and-egg problem for the future implementer of such features, that's OK) - I'd essentially implement it that way. Put DEFAULTED_out_of_class on the member function definition DIE if it's defaulted there, and put DEFAULTED_in_class on the declaration DIE if it's defaulted there.

And I'd probably only spend one bit of flags on this, if possible - "not defaulted (0/assumed for all subprograms) or defaulted (1)" and translate it into one of the two values (in_class or out_of_class) in the backend based on which subprogram DIE it's attached to.

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

https://reviews.llvm.org/D68117