Next batch of -Wgnu flags

I'm currently waiting for approval or feedback on adding the following GNU flags in the -Wgnu group:

gnu-binary-literal
gnu-imaginary-constant
gnu-line-zero-directive
gnu-token-pasting-comma
gnu-zero-variadic-macro-arguments

And then the next batch of names (which I've done already) is:

gnu-anonymous-struct
gnu-compound-literal-initializer
gnu-empty-struct
gnu-flexible-array-initializer
gnu-flexible-array-union-member
gnu-folding-initializer-constant
gnu-folding-integer-constant
gnu-only-flexible-array-member
gnu-redeclared-class-member
gnu-redeclaration-enum
gnu-struct-without-named-member
gnu-union-cast
gnu-variable-sized-type-not-at-end

Personally, I very much want to be able to use the style -Weverything -Wno-specific-things, which is why I'm doing this, so I'd not have strong opinions on what the flags are called, I've done my best to name them appropriately, but my goal is to ensure there is one flag for each feature so I don't have to enable more features than I have justified using.

If you're wondering about the kinds of things that generate the various warnings, I've included snippets of the test cases below that show the options.

Thanks for any feedback that might help speed up the process,
   Peter.

#if ALL || ZEROARGS
// expected-warning@+11 {{must specify at least one argument for '...' parameter of variadic macro}}
// expected-note@+6 {{macro 'efoo' defined here}}
#endif
#if ALL || TOKENPASTING
// expected-warning@+3 {{token pasting of ',' and __VA_ARGS__ is a GNU extension}}
#endif

#define efoo(format, args...) foo(format , ##args)

void foo( const char* c )
{
  efoo("6");
}

#if ALL || IMAGINARYCONST
// expected-warning@+3 {{imaginary constants are a GNU extension}}
#endif

float _Complex c = 1.if;

#if ALL || BINARYLITERAL
// expected-warning@+3 {{binary integer literals are a GNU extension}}
#endif

int b = 0b0101;

// This case is handled differently because lit has a bug whereby #line 0 is reported to be on line 4294967295
// http://llvm.org/bugs/show_bug.cgi?id=16952
#if ALL || LINE0
#line 0 // expected-warning {{#line directive with zero argument is a GNU extension}}
#else
#line 0
#endif

#if ALL || ANONYMOUSSTRUCT
// expected-warning@+5 {{anonymous structs are a GNU extension}}
#endif

struct as {
  int x;
  struct {
    int a;
    float b;
  };
};

#if ALL || REDECLAREDCLASSMEMBER
// expected-note@+6 {{previous declaration is here}}
// expected-warning@+6 {{class member cannot be redeclared}}
#endif

namespace rcm {
  class A {
    class X;
    class X;
    class X {};
  };
}

#if ALL || FLEXIBLEARRAYUNIONMEMBER
// expected-warning@+6 {{flexible array member 'c1' in a union is a GNU extension}}
#endif

struct faum {
   int l;
   union {
       int c1[];
   };
};

#if ALL || FOLDINGINITIALIZERCONSTANT
// expected-warning@+4 {{in-class initializer for static data member is not a constant expression; folding it to a constant is a GNU extension}}
#endif

struct fic {
  static const int B = int(0.75 * 1000 * 1000);
};

#if ALL || COMPOUNDLITERALINITIALIZER
// expected-warning@+4 {{initialization of an array of type 'int [5]' from a compound literal of type 'int [5]' is a GNU extension}}
#endif

typedef int int5[5];
int cli[5] = (int[]){1, 2, 3, 4, 5};

#if ALL || EMPTYSTRUCT
// expected-warning@+4 {{empty struct is a GNU extension}}
#endif

const struct {} es;

#if ALL || FLEXIBLEARRAYINITIALIZER
// expected-note@+6 {{initialized flexible array member 'y' is here}}
// expected-warning@+6 {{flexible array initialization is a GNU extension}}
#endif

struct fai {
  int x;
  int y[];
} fai = { 1, { 2, 3, 4 } };

#if ALL || FOLDINGINTEGERCONSTANT
// expected-warning@+4 {{expression is not an integer constant expression; folding it to a constant is a GNU extension}}
#endif

enum {
  fic = (int)(0.75 * 1000 * 1000)
};

#if ALL || ONLYFLEXIBLEARRAYMEMBER
// expected-warning@+5 {{flexible array member 'a' in otherwise empty struct is a GNU extension}}
#endif

struct ofam
{
   int a[];
};

#if ALL || REDECLARATIONENUM
// expected-note@+6 {{previous definition is here}}
// expected-warning@+5 {{redeclaration of already-defined enum 'RE' is a GNU extension}}
#endif

enum RE {
  Val1,
  Val2
};

enum RE;

#if ALL || STRUCTWITHOUTNAMEDMEMBER
// expected-warning@+3 {{struct without named members is a GNU extension}}
#endif

struct {int:5;} swnm;

#if ALL || UNIONCAST
// expected-warning@+4 {{cast to union type is a GNU extension}}
#endif

union uc { int i; unsigned : 3; };
union uc w = (union uc)2;

#if ALL || VARIABLESIZEDTYPENOTATEND
// expected-warning@+4 {{field 'hdr' with variable sized type 'struct vst' not at the end of a struct or class is a GNU extension}}
#endif

struct vst {
short tag_type;
char tag_data[];
};
struct vstnae {
  struct vst hdr;
  char data;
};

I'm currently waiting for approval or feedback on adding the following GNU flags in the -Wgnu group:

Rather than starting different email threads, the best approach is to
ping your original review emails (reply to the original email you sent
to the -commits list with the patch re-attached & simply the word
"ping" (and/or the number of times you've pinged, so people get a
sense of how long you've been waiting)).

I'm currently waiting for approval or feedback on adding the following GNU flags in the -Wgnu group:

Rather than starting different email threads, the best approach is to
ping your original review emails (reply to the original email you sent
to the -commits list with the patch re-attached & simply the word
"ping" (and/or the number of times you've pinged, so people get a
sense of how long you've been waiting)).

I was going to do that with the patch for batch 2 (the first set of five flags below) after I'd given folks the weekend to comment.

This email was largely designed to get any comments on the third batch (the set of 13 below) before submitting the patch.

I hope that's ok, but if not, I wont do it like this again.
   Peter.

I'm currently waiting for approval or feedback on adding the following GNU flags in the -Wgnu group:

Rather than starting different email threads, the best approach is to
ping your original review emails (reply to the original email you sent
to the -commits list with the patch re-attached & simply the word
"ping" (and/or the number of times you've pinged, so people get a
sense of how long you've been waiting)).

I was going to do that with the patch for batch 2 (the first set of five flags below) after I'd given folks the weekend to comment.

This email was largely designed to get any comments on the third batch (the set of 13 below) before submitting the patch.

Might as well just send the patch for review to cfe-commits, if you've
already got it.

I hope that's ok, but if not, I wont do it like this again.

All good - not wrong, just explaining the easiest/hopefully most
effective approach.

gnu-empty-struct, gnu-struct-without-named-member, and
gnu-only-flexible-array-member are all variants of the same extension
(allowing structs without a named member); it probably makes sense to put
them all under gnu-empty-struct.

gnu-folding-initializer-constant and gnu-folding-integer-constant are also
variants of the same extension (along with ext_vla_folded_to_constant)

gnu-redeclared-class-member probably shouldn't have "gnu" in the name; it's
not really an intentional extension.

(This isn't a formal review; please continue to submit patches as you have
been doing.)

-Eli

I'm currently waiting for approval or feedback on adding the following
GNU flags in the -Wgnu group:

gnu-binary-literal

This is also a C++1y language extension; we should put it under
-Wc++1y-extensions in C++ mode, and under -Wgnu-binary-literal in C mode.

gnu-imaginary-constant

gnu-line-zero-directive

Maybe -Wgnu-#line-0? (We have precedent for # in a warning name:
-W#warnings, -W#pragma-messages)

gnu-token-pasting-comma

gnu-zero-variadic-macro-arguments

These two are the definition and use side of the same feature, so should
probably live under the same flag.

And then the next batch of names (which I've done already) is:

gnu-empty-struct, gnu-struct-without-named-member, and gnu-only-flexible-array-member are all variants of the same extension (allowing structs without a named member); it probably makes sense to put them all under gnu-empty-struct.

OK, I'll use that when I submit the patch.

gnu-folding-initializer-constant and gnu-folding-integer-constant are also variants of the same extension (along with ext_vla_folded_to_constant)

OK, I'll use that when I submit the patch. I will try to add it for ext_vla_folded_to_constant as well.

gnu-redeclared-class-member probably shouldn't have "gnu" in the name; it's not really an intentional extension.

So just -Wredeclared-class-member? Ok, can do.

(This isn't a formal review; please continue to submit patches as you have been doing.)

Yep, it was probably a mistake to post here, just figured I'd give people an opportunity to comment on the flag names independent of the code review.

>gnu-binary-literal

This is also a C++1y language extension; we should put it under -Wc++1y-extensions in C++ mode, and under -Wgnu-binary-literal in C mode.

OK, I'll look in to adding that as a follow on patch after the current one is submitted.

>gnu-line-zero-directive

Maybe -Wgnu-#line-0? (We have precedent for # in a warning name: -W#warnings, -W#pragma-messages)

gnu-token-pasting-comma
gnu-zero-variadic-macro-arguments

These two are the definition and use side of the same feature, so should probably live under the same flag.

I've changed the patch (see clang-commits thread " [PATCH] Add more specific lexer flags for misc GNU extensions") to use -Wgnu-zero-variadic-macro-arguments for both of those, and -Wgnu-zero-line-directive for -Wgnu-zero-line-directive. If people prefer -Wgnu-#line-0 to -Wgnu-zero-line-directive, I can update that patch as well. Probably best to post on the commits thread for that - I probably shouldn't have posted here, and definitely shouldn't have mentioned the flags in the patch on the commits thread. My apologies for that, it wont happen again.
   Peter.