https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44317
Harald van Dijk <harald at gigawatt dot nl> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |harald at gigawatt dot nl
--- Comment #9 from Harald van Dijk <harald at gigawatt dot nl> ---
The comma should not be eaten, as the invocation of FAIL() is valid in standard
C++. The rules of concatenation of empty pp-token sequences are well-defined:
the empty sequences are replaced by placemarker preprocessor tokens, and
concatenating any non-placeholder token with a placemarker preprocessor token
produces the former, see [cpp.concat]. There is no exception for commas.
Because of that, in that one special case where ,##__VA_ARGS__ is valid in both
standard C++ and GNU C++ with different meanings, the standard C++ meaning is
used in standard C++ modes, and the GNU C++ meaning is used in GNU C++ modes.
If clang provides no option to let <FAIL()> expand to standard C++'s
<SomeClass(),> rather than GNU C++'s <SomeClass()>, that is a clang bug, not a
GCC bug. (clang does behave correctly in C99/C11 modes.)
That's different from the ASSERT( false ) invocation: since that invocation is
invalid in standard C++ regardless of whether the definition uses __VA_ARGS__,
the invocation is diagnosed. Once the diagnostic is emitted, if GCC continues
to accept the code as an extension, the standard places no requirements on its
behaviour. GCC is free to change the meaning of ,##__VA_ARGS__ in that case,
and no standard requires any further diagnostics for it.
Extending GCC with an additional warning for diagnosing ,##__VA_ARGS__ as a GNU
extension may make sense even despite that, but please do not change what
,##__VA_ARGS__ expands to. GCC is already correct there.
