Open Quuxplusone opened 5 years ago
Since VA_OPT is a reserved identifier, enabling the use of VA_OPT in all language modes should be fine. A gratuitous difference from GCC is not desirable.
Perhaps, but this might just be a mistake in GCC's implementation that gets fixed later. It would be better if we talked to the GCC folks and come to an agreement what the correct behaviour is and then implement the same (or at least very similar) in both GCC and Clang.
Attached varargs.cxx
(155 bytes, text/plain): example program
For convenience. Here's the program on Godbolt. https://godbolt.org/z/USde4M
We generally accept conforming extensions such as this in prior language modes. Unless there's a reason not to do so, we should accept __VA_OPT__ in all language modes (with an Extension or ExtWarn diagnostic) irrespective of what GCC does.
varargs.cxx
(155 bytes, text/plain)The attached program can be compiled by GCC 8.2.1 in various language modes
but Clang fails to compile it because the
__VA_OPT__()
macro does not get expanded for all of the above language variants except forc++2a
andgnu++2a
.I believe
__VA_OPT_()
is a C++2a feature so Clang is probably more correct here.However according to https://gcc.gnu.org/onlinedocs/cpp/Variadic-Macros.html
__VA_OPT_()
is supposed to be available for GNU C and GNU C++ too so we probably ought to enable it when we are compiling for the GNU language variants-std=gnu*
.The fact that GCC allows
__VA_OPT__()
in non-GNU language variants that isn'tc++2a
seems like a bug but I am not currently in a position to report it.