[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#2526317 <https://reviews.llvm.org/D91913#2526317>, @hvdijk wrote:

> In D91913#2526117 <https://reviews.llvm.org/D91913#2526117>, @rsmith wrote:
>
>> I think @rnk's observation that `__VA_OPT__` isn't actually available in any compilation mode other than C++20 (which I hadn't previously realized) is important here: we'd left longstanding users of this functionality with no path forward, and that is, I think, sufficient motivation for a revert.
>
> My concern isn't with the revert itself, it's without waiting for approval. That's a crystal clear LLVM developer policy violation: changes need to be approved, or obvious, or by developers responsible for the code being modified. @rnk himself has linked to the page making this clear, just before the bit he linked to: https://llvm.org/docs/CodeReview.html#must-code-be-reviewed-prior-to-being-committed. The fact that reviews don't close after committing does not change that.

Commits and reverts are not held to the same standards. We expect changes to be reverted early, and generally encourage patches to be reverted as a first response if problems are discovered (soon) after the original commit. This is all part of keeping trunk clean, which is to everyone's benefit.

> "Longstanding users" is not right: there has not been any indication that this affected anyone other than Google. (Except for the MSVC compatibility issue.)
> "No path forward" is not right either: Google already had multiple paths forward.

Problems with early adopters are signs that others will have problems too. And none of the paths forward that you mentioned are really reasonable and proportionate, given the small scale of the problem that this change addresses.

Fundamentally, while we *can* change Clang trunk to do anything we like, we shouldn't: we need to have respect for our users, their time, and their existing codebases. And that means making changes like this in a responsible fashion, giving notice, and responding well when we hear that the change has caused problems in practice. This change is not urgent, and by moving more slowly, we can significantly reduce the cost on our users of adapting to it.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D91913