Re: PR C++/88114 - patch for destructor not generated for "virtual ~destructor() = default"

[Jason Merrill <jason@redhat.com>]

On 1/11/19 1:36 PM, Tobias Burnus wrote:
> Dear Jason, dear all,
> 
> Jason Merrill wrote on 5 Dec 2018:
>> You can get at the destructor with CLASSTYPE_DESTRUCTOR rather than walking through TYPE_FIELDS. I'd also check DECL_DEFAULTED_IN_CLASS_P.
>> I'd also do this in maybe_emit_vtables rather than here, so that it only happens once per class.
> 
> Updated patch. I also added a test case which checks that the destructor
> is not generated.
> 
> [ Original patch: https://gcc.gnu.org/ml/gcc-patches/2018-11/msg01824.html ]
> 
> Background again:
>     If a class contains any 'virtual ... = 0', it's an abstract class and for an
>     abstract class, the destructor not added to the vtable.
> 
>     For a normal
>       virtual ~class() { }
>     that's not a problem as the class::~class() destructor will be generated during
>     the parsing of the function.
> 
>     But for
>       virtual ~class() = default;
>     the destructor will be generated via mark_used via the vtable.
> 
>     If one now declares a derived class and uses it, the class::~class() is generated
>     in that translation unit.  Unless, #pragma interface/implementation is used.
> 
>     In that case, the 'default' destructor will never be generated.
> 
> Build and regtested on x86_64-gnu-linux.
> OK? Or do you have more suggested changes?

> +      && DECL_DEFAULTED_IN_CLASS_P(CLASSTYPE_DESTRUCTOR(ctype))
> +      && DECL_DEFAULTED_FN (CLASSTYPE_DESTRUCTOR(ctype)))

Checking DECL_DEFAULTED_FN again is redundant, it's checked by 
DECL_DEFAULTED_IN_CLASS_P.  OK with that last condition removed.

Jason