Should #elifdef and #elifndef have a portability warning?

[AaronBallman]

These are new features of C2x, but they're supported as a conforming extension in older versions of Clang. However, there's no pedantic warning given about them being a Clang extension in older language modes, so users may be surprised when porting to another compiler. See https://godbolt.org/z/MdK476q7b as an example. Should we be issuing a pedantic warning here?

[llvmbot]

@llvm/issue-subscribers-clang-frontend

[llvmbot]

@llvm/issue-subscribers-good-first-issue

[josephcsible]

I think this is a good idea, as long as the warning will only trigger when you're actually using the older language modes (unlike, e.g., -Wc++98-compat, where x = nullptr; triggers it even in newer language modes).

[AaronBallman]

-Wc++98-compat is intended to warn you about all code constructs that are not compatible with the given language version, so it's only purpose is to fire in newer language modes.

The plan is for this diagnostic to behave like our other pairs of compat/extension warnings. e.g., Given

#ifdef FOO
#elifdef BAR
#endif

in pedantic C17 mode, we'll issue a "use of this is a C2x extension" warning, and in C2x mode with -Wpre-c2x-compat (which is default ignored), we'll issue a "use of this feature is not compatible with standards before C2x" warning. (And similar for C++ modes.)