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

_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to