[clang] Add tests for CWG issues 6, 212, 232, 2823. (PR #165633)

[Vlad Serebrennikov via cfe-commits]

================
@@ -0,0 +1,31 @@
+// RUN: %clang_cc1 -std=c++98 %s -triple x86_64-linux-gnu -emit-llvm -o - -fexceptions -fcxx-exceptions -pedantic-errors | FileCheck %s --check-prefixes CHECK
+// RUN: %clang_cc1 -std=c++11 %s -triple x86_64-linux-gnu -emit-llvm -o - -fexceptions -fcxx-exceptions -pedantic-errors | FileCheck %s --check-prefixes CHECK
+// RUN: %clang_cc1 -std=c++14 %s -triple x86_64-linux-gnu -emit-llvm -o - -fexceptions -fcxx-exceptions -pedantic-errors | FileCheck %s --check-prefixes CHECK
+// RUN: %clang_cc1 -std=c++17 %s -triple x86_64-linux-gnu -emit-llvm -o - -fexceptions -fcxx-exceptions -pedantic-errors | FileCheck %s --check-prefixes CHECK
+// RUN: %clang_cc1 -std=c++20 %s -triple x86_64-linux-gnu -emit-llvm -o - -fexceptions -fcxx-exceptions -pedantic-errors | FileCheck %s --check-prefixes CHECK
+// RUN: %clang_cc1 -std=c++23 %s -triple x86_64-linux-gnu -emit-llvm -o - -fexceptions -fcxx-exceptions -pedantic-errors | FileCheck %s --check-prefixes CHECK
+// RUN: %clang_cc1 -std=c++2c %s -triple x86_64-linux-gnu -emit-llvm -o - -fexceptions -fcxx-exceptions -pedantic-errors | FileCheck %s --check-prefixes CHECK
+
+namespace cwg6 { // cwg6: yes
----------------
Endilll wrote:

> We shouldn't be describing the versions of Clang that accept the test (that's irrelevant to our users); we should instead be describing the versions of Clang that implement the issue resolution.

When it comes to conformance tests (which I assume DR tests are a part of), I don't agree that users care when we implemented the resolution (or tried to) — it might take several patches to get things right. Instead they care whether Clang behaves as described in the resolution. If a test is not sufficient to determine that, it should be improved. I guess I'm coming from "DR tests are written against the wording in the Core issue and are informed by the implementation if it is available" perspective, which might be different from yours.

> (If it's important that the test passes on the same versions of Clang that we report, then perhaps we could #define static_assert to use the array hack for old versions of Clang instead of reporting imprecise versions in our status table? But that seems like it should be a non-goal to me.)

I wouldn't go as far as asking tests to be written in a way that works in those old versions. When I was replacing `Yes` with version numbers, I had a bunch of support macros. One of them indeed implemented `static_assert` using array hack I've seen so many times in DR tests (now retired in favor of `_Static_assert`).

> I don't think we should mark this 3.1 just because part of the test we're using here happens to not work on Clang 3.0.

For the record, it doesn't seem to be an issue with `static_assert`, because applying array hack doesn't help: https://godbolt.org/z/EcY6hP97e. 2.9 works as expected, so it's really a quirk of 3.0 (one of many; versions prior to 3.3 had a lot of regressions in my experience).

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