c++ build flags, clang++, -Wnomismatched-tags?

c++ build flags, clang++, -Wnomismatched-tags?

[Matt Benjamin]

Hi Ceph C++ devs,

I notice building with clang lots of warnings like:

      'SequencerPosition' defined as a struct here but previously declared as a
      class [-Wmismatched-tags]
struct SequencerPosition {
^
/home/mbenjamin/dev/rgw/ceph-upstream/src/os/ObjectMap.h:24:1: note: did you
      mean struct here?
class SequencerPosition;
^~~~~
struct
3 warnings generated.

induced by -Wmismatched-tags, which apparently clang++ has by default.  As a ISO C++ developer, I don't think of "struct" as a token that can be mismatched with "class" in friend or forward declaration, but clearly the authors of this warning do.

I think my intuition would be to disable this warning.  What do others think?

Matt

-- 
Matt Benjamin
Red Hat, Inc.
315 West Huron Street, Suite 140A
Ann Arbor, Michigan 48103

http://www.redhat.com/en/technologies/storage

tel.  734-707-0660
fax.  734-769-8938
cel.  734-216-5309

Re: c++ build flags, clang++, -Wnomismatched-tags?

[Sage Weil]

On Wed, 20 Jan 2016, Matt Benjamin wrote:
> Hi Ceph C++ devs,
> 
> I notice building with clang lots of warnings like:
> 
>       'SequencerPosition' defined as a struct here but previously declared as a
>       class [-Wmismatched-tags]
> struct SequencerPosition {
> ^
> /home/mbenjamin/dev/rgw/ceph-upstream/src/os/ObjectMap.h:24:1: note: did you
>       mean struct here?
> class SequencerPosition;
> ^~~~~
> struct
> 3 warnings generated.
> 
> induced by -Wmismatched-tags, which apparently clang++ has by default.  As a ISO C++ developer, I don't think of "struct" as a token that can be mismatched with "class" in friend or forward declaration, but clearly the authors of this warning do.
> 
> I think my intuition would be to disable this warning.  What do others 
> think?

No arguments from me, although I wouldn't object to someone who wants to 
clean up the mismatches either.

sage

Re: c++ build flags, clang++, -Wnomismatched-tags?

[Matt Benjamin]

My annoyance with this warning is that I don't really want to see "friend struct foo" decls, which seems vaguely bogus?  The warnings could be eliminated by using class everywhere and adding public specifier where expected--but we shouldn't have to do that...

Matt

----- Original Message -----
> From: "Sage Weil" <sage@newdream.net>
> To: "Matt Benjamin" <mbenjamin@redhat.com>
> Cc: "Ceph Development" <ceph-devel@vger.kernel.org>
> Sent: Wednesday, January 20, 2016 5:57:17 PM
> Subject: Re: c++ build flags, clang++, -Wnomismatched-tags?
> 
> On Wed, 20 Jan 2016, Matt Benjamin wrote:
> > Hi Ceph C++ devs,
> > 
> > I notice building with clang lots of warnings like:
> > 
> >       'SequencerPosition' defined as a struct here but previously declared
> >       as a
> >       class [-Wmismatched-tags]
> > struct SequencerPosition {
> > ^
> > /home/mbenjamin/dev/rgw/ceph-upstream/src/os/ObjectMap.h:24:1: note: did
> > you
> >       mean struct here?
> > class SequencerPosition;
> > ^~~~~
> > struct
> > 3 warnings generated.
> > 
> > induced by -Wmismatched-tags, which apparently clang++ has by default.  As
> > a ISO C++ developer, I don't think of "struct" as a token that can be
> > mismatched with "class" in friend or forward declaration, but clearly the
> > authors of this warning do.
> > 
> > I think my intuition would be to disable this warning.  What do others
> > think?
> 
> No arguments from me, although I wouldn't object to someone who wants to
> clean up the mismatches either.
> 
> sage
> --
> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

-- 
-- 
Matt Benjamin
Red Hat, Inc.
315 West Huron Street, Suite 140A
Ann Arbor, Michigan 48103

http://www.redhat.com/en/technologies/storage

tel.  734-707-0660
fax.  734-769-8938
cel.  734-216-5309

Re: c++ build flags, clang++, -Wnomismatched-tags?

[Gregory Farnum]

On Wed, Jan 20, 2016 at 3:07 PM, Matt Benjamin <mbenjamin@redhat.com> wrote:
> My annoyance with this warning is that I don't really want to see "friend struct foo" decls, which seems vaguely bogus?  The warnings could be eliminated by using class everywhere and adding public specifier where expected--but we shouldn't have to do that...

Do we know what other class of issues this flag warns us on? I
actually think it might be good to be consistent about the
struct/class distinction but don't have a strong opinion on it as long
as we aren't masking something else by zapping the warning.
-Greg

>
> Matt
>
> ----- Original Message -----
>> From: "Sage Weil" <sage@newdream.net>
>> To: "Matt Benjamin" <mbenjamin@redhat.com>
>> Cc: "Ceph Development" <ceph-devel@vger.kernel.org>
>> Sent: Wednesday, January 20, 2016 5:57:17 PM
>> Subject: Re: c++ build flags, clang++, -Wnomismatched-tags?
>>
>> On Wed, 20 Jan 2016, Matt Benjamin wrote:
>> > Hi Ceph C++ devs,
>> >
>> > I notice building with clang lots of warnings like:
>> >
>> >       'SequencerPosition' defined as a struct here but previously declared
>> >       as a
>> >       class [-Wmismatched-tags]
>> > struct SequencerPosition {
>> > ^
>> > /home/mbenjamin/dev/rgw/ceph-upstream/src/os/ObjectMap.h:24:1: note: did
>> > you
>> >       mean struct here?
>> > class SequencerPosition;
>> > ^~~~~
>> > struct
>> > 3 warnings generated.
>> >
>> > induced by -Wmismatched-tags, which apparently clang++ has by default.  As
>> > a ISO C++ developer, I don't think of "struct" as a token that can be
>> > mismatched with "class" in friend or forward declaration, but clearly the
>> > authors of this warning do.
>> >
>> > I think my intuition would be to disable this warning.  What do others
>> > think?
>>
>> No arguments from me, although I wouldn't object to someone who wants to
>> clean up the mismatches either.
>>
>> sage
>> --
>> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
>
> --
> --
> Matt Benjamin
> Red Hat, Inc.
> 315 West Huron Street, Suite 140A
> Ann Arbor, Michigan 48103
>
> http://www.redhat.com/en/technologies/storage
>
> tel.  734-707-0660
> fax.  734-769-8938
> cel.  734-216-5309
> --
> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: c++ build flags, clang++, -Wnomismatched-tags?

[Ilya Dryomov]

On Thu, Jan 21, 2016 at 12:49 AM, Gregory Farnum <gfarnum@redhat.com> wrote:
> On Wed, Jan 20, 2016 at 3:07 PM, Matt Benjamin <mbenjamin@redhat.com> wrote:
>> My annoyance with this warning is that I don't really want to see "friend struct foo" decls, which seems vaguely bogus?  The warnings could be eliminated by using class everywhere and adding public specifier where expected--but we shouldn't have to do that...
>
> Do we know what other class of issues this flag warns us on? I
> actually think it might be good to be consistent about the
> struct/class distinction but don't have a strong opinion on it as long
> as we aren't masking something else by zapping the warning.

I think the reason this warning exists has to do with Microsoft
compilers, which used to (?) mangle structs and classes differently,
leading to link errors.

From the errata to Herb Sutter's "Exceptional C++" [1]:

"It's perfectly legal and standards-conforming to forward-declare
a class as a struct and vice versa. In most of the book I've tended to
avoid doing that, though. Why? Only because some compilers are buggy
and still don't get this right -- e.g., by name-mangling a class and
a struct differently, which will cause the linker to fail to match them
up. Such compiler bugs really are bugs and are wrong, but they're
common enough that we might as well avoid the issue by not relying on
this standard feature. Sigh."

It looks like MSVC 6 at least was among those compilers.  I assume it
was fixed, but this warning is still there in the latest Visual Studio [2].

[1] http://www.gotw.ca/publications/xc++-errata.htm
[2] https://msdn.microsoft.com/en-us/library/695x5bes.aspx

I doubt there is anything else we would mask by zapping it.

Thanks,

                Ilya