[PATCH] D91913: Suppress non-conforming GNU paste extension in all standard-conforming modes

[Richard Smith - zygoloid via Phabricator via cfe-commits]

rsmith added a comment.

In D91913#2521031 <https://reviews.llvm.org/D91913#2521031>, @thakis wrote:

> In D91913#2520503 <https://reviews.llvm.org/D91913#2520503>, @hvdijk wrote:
>
>> Chrome `-std=c++*` when building with clang, but `-std=gnu++*` when building with GCC for exactly this reason, see build/config/compiler/BUILD.gn. Chrome should use `-std=gnu++*` with clang too.
>
> We (and every other project out there) needs some incremental rollout plan for this. We don't want to allow _more_ GNU features. Please put this behind a `-f` toggle, or revert this for a bit implementing this takes some time.

I'm definitely sympathetic to wanting to avoid further use of GNUisms sneaking into your codebase. We're in a tricky position, though, if our choices are that either we add a `-f` flag for this, end up maintaining fine-grained GNU language mode flags which we don't want, and have a hard time removing those flags, or you enable all GNU language changes, and have to work to avoid them being used / have a hard time ever switching back to `-std=c++*`. I'd be OK with the fine-grained flag if we could reasonably plan to remove after one or two Clang releases, but these things have a tendency to never go away.

We have another option: we could restore the old behavior for the Clang 12 release branch (branching tomorrow!), and add a warning to the release branch for uses of the comma paste extension in modes where we want to remove it, so that people have a release cycle to transition before we actually make the change in anger. That would probably be the most comfortable path forward, with the least time pressure all around.

However, there are a couple of additional problems:

- There doesn't seem to be any kind of feature test macro for `__VA_OPT__`, so people can't easily use it when available and fall back on comma paste otherwise. I've suggested to WG21 that we allow use of `#ifdef __VA_OPT__` (and `#ifndef __VA_OPT__` and `defined(__VA_OPT__)`) for this.
- We still retain the comma paste semantics in all cases if there is at least one named parameter. Historically, the rationale for that has been that omitting the final comma in such cases was ill-formed, but that is no longer the case in C++20 onwards, with the advent of `__VA_OPT__`. So we should be working towards removing the `getNumParams() < 2` check in at least the C++20 case.

So perhaps this might be a reasonable plan:

For Clang 12:

- Undo the semantic change and add a warning on comma pastes that will change meaning on Clang 13.
- Add feature test support for `__VA_OPT__` via `#ifdef __VA_OPT__`.
- Clearly document in the release notes that this is going to change in Clang 13, and that `__VA_OPT__` should be used instead for users who don't want to enable GNU mode or `-fms-compatibility`.

For Clang 13:

- Disable comma paste for macros with named parameters in `-std=c89` and `-std=c++98` through `-std=c++17`; disable comma paste for all macros in `-std=c++20` onwards.
- (Also add feature test support for `__VA_OPT__`.)

Thoughts?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D91913/new/

https://reviews.llvm.org/D91913