[PATCH 1/3] add -Wstruct-not-pod, -Wclass-is-pod, -Wmismatched-tags (PR 61339)

[Mike Stump]

On Jul 22, 2019, at 3:19 PM, Jeff Law <law@redhat.com> wrote:
> 
> On 7/8/19 3:58 PM, Martin Sebor wrote:
>> The attached patch implements three new warnings:
>> 
>>  *  -Wstruct-not-pod triggers for struct definitions that are not
>>     POD structs,
>>  *  -Wclass-is-pod triggers for class definitions that satisfy
>>     the requirements on POD structs, and
>>  *  -Wmismatched-tags that triggers for class and struct declarations
>>     with class-key that doesn't match either their definition or
>>     the first declaration (if no definition is provided).
>> 
>> The implementation of -Wclass-is-pod and -Wstruct-not-pod is fairly
>> straightforward but the -Wmismatched-tags solution is slightly unusual.
>> It collects struct and class declarations first and diagnoses mismatches
>> only after the whole tramslation unit has been processed.  This is so
>> that the definition of a class can guide which declarations to diagnose
>> no matter which come first.
> So there was some discussion on whether or not we even wanted to keep
> the struct vs class convention for GCC.
> 
> Did that reach any kind of conclusion?

Last I knew, the consensus was to accept patches that make the usage of struct and class consistent (no warning from clang by default, no defeat necessary).  I don't recall if it was settled if patches would be rejected merely because they they were not consistent.  I'd think we'd not reject patches on those grounds, but rather, let the people that build on clang style systems front the work, and contribute if they want.

But, I have a long memory, and the above might be a consensus or two ago.  :-)  I glanced around, and my google-fu turned up [1] and [2].

1 - https://gcc.gnu.org/PR61339
2 - https://gcc.gnu.org/wiki/FAQ#Wmismatched-tags

Kinda annoying to have a complaint for this, for no other reason other than a bad MS compiler.  It seems to have infected clang, and now in danger of infecting gcc, all for no good reason.  I'd rather MS remove the warning, clang remove the warning, and be done with the whole mess.  Oh well.  In 20 more years, no one will even recall why we had the warning and/or won't question it's existence.