[clang] [libcxx] [SemaCXX] Implement CWG2137 (list-initialization from objects of the same type) (PR #77768)

[via cfe-commits]

alexfh wrote:

> > As I understood the author, more time was needed to prepare the tests and the fix. I just tried to bring the tip of the tree to a good state soon (our internal release process was blocked on this) without putting any pressure on the author.
> 
> Typically when the author is engaging fairly quickly and only needs a short time (he had already identified the problem and only had process-related concerns), it is preferred to be understanding/polite and give them time to work on it.

First of all, let me quote the developer policy: ["Remember, it is normal and healthy to have patches reverted. Having a patch reverted does not necessarily mean you did anything wrong."](https://llvm.org/docs/DeveloperPolicy.html#patch-reversion-policy). Now, I totally understand the desire to "capture the progress" as well as frustration one might have seeing their work reverted. However, a revert shouldn't be perceived as an impolite or unfriendly action. All contributions are welcome and appreciated. Reverting a commit is merely a way to deal with problems one at a time without blocking others or racing against the clock.

Frequently, it is the most sustainable way forward that helps keeping the tip of the tree in a reasonably good shape while not putting unnecessary time pressure on contributors. ["As a community, we strongly value having the tip of tree in a good state while allowing rapid iterative development. As such, we tend to make much heavier use of reverts to keep the tree healthy than some other open source projects, and our norms are a bit different."](https://llvm.org/docs/DeveloperPolicy.html#patch-reversion-policy)

A quick and obvious forward fix is also an option sometimes, but though there are certain signals like fast responses from all involved parties, the time to get a **correct** fix into the tree is unpredictable in general. Sometimes, an "obvious" fix turns out to be suboptimal or just wrong, which can be found during a review or much later - after it's committed and tested (by us or other users). For example, I got a quick response here, but now, two days later the fix hasn't been even sent for review (and this is totally fine, since the problematic commit is reverted, and the author can work in their pace and with their own priorities).

Things get even more complicated, when a problem is long enough in the tree and other problems start to pile up. It's a matter of just two-three sufficiently widespread issues being simultaneously in the tree, when even finding the culprit for each problem becomes much longer and requires more effort. Been there, done that. For example, this week we've already seen a handful of clang bugs affecting the same files, leading to them be hidden behind each other.

> While I am sympathetic to your internal processes, it seems to me that they should be more tolerant of a ToT that is not particularly stable, as is the case with Clang.

You may be surprised, but ToT Clang (as well as LLVM in general) is quite stable. Our release process ensures that every week or so there is an LLVM revision that requires just a handful of cherrypicks (sometimes, no cherrypicks at all) to correctly compile all of our code, which, given the immense size, is a pretty high bar (though, this obviously applies only to the configurations and targets we use).

https://github.com/llvm/llvm-project/pull/77768