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
