Re: [PATCH 2/2] PR debug/63240 Add DWARF representation for C++11 defaulted member function.

[Mark Wielaard <mjw at redhat dot com>]

On Fri, 2014-10-03 at 10:17 -0400, Jason Merrill wrote:
> On 10/03/2014 09:12 AM, Mark Wielaard wrote:
> > A debugger not knowing whether a special member function was explicitly
> > defaulted, implicitly declared or explicitly defined seems less confusion
> > than not knowing whether it was deleted. But there are some subtle cases
> > where knowing whether a constructor was user defined or explicitly
> > defaulted do matter for whether the default constructor might have been
> > implicitly generated.
> 
> Can you elaborate?

Say you have a user defined copy constructor. The DWARF consumer will
see the declaration and can assume the class won't have a default
constructor (unless that one is explicitly declared too). But currently
the DWARF consumer cannot know whether that move constructor was really
a user defined. If it was declared with = default; then it will see the
move constructor and erroneously conclude that it was user defined and
so the class won't have a default constructor generated for it. Having
the defaulted attribute on the declaration makes clear that the special
function member wasn't in fact user defined. This is because gcc doesn't
output implicit special member function declarations.

> > So like the deleted case this patch introduces
> > a new attribute DW_AT_GNU_defaulted that gets attached to the function
> > declaration. Note that since this is for declarations we explicitly
> > test for DECL_DEFAULTED_IN_CLASS_P and ignore any implementation
> > definitions that use = default; outside the class body.
> 
> Hmm, I'm dubious about this choice.  How do you expect a consumer to use 
> this information?

In two ways. First simply to let the debugger more accurately show the
declaration of the class. Just like one uses = default; in their source
code to be explicit about the fact that the special member function was
really desired. It would be nice if the debugger could provide the same
source information.

Secondly, as described above. There is a difference between = default;
on the declaration and on the implementation definition. If the out of
class definition of a special member function has an = default; then the
in class declaration cannot have it. That means that a = default; on the
out of class definition actually means that the function is user defined
(it just happens to be defined by the default implementation). While a =
default; on the in class declaration means it explicitly isn't user
defined. The consumer can use this information to deduce which implicit
member functions are available.

Cheers,

Mark