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

[Richard Smith 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
----------------
zygoloid wrote:

> 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 their Clang version behaves as described in the resolution.

I think we're in agreement here. By "the versions of Clang that implement the issue resolution", I mean the ones that get it right, not merely the ones that try to :)

> 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).

It looks like what you're seeing is an issue with constant evaluation, which is an artifact of how this issue is being tested, rather than suggesting that we don't implement it. All versions of Clang follow the direction of CWG 6; we have never implemented some magical copy elision for function parameters, and it'd be misleading to suggest we have, just because Clang 3.0 had some other bug in its constant evaluator. It might be that there's no way to observe that through constant evaluation in Clang 3.0, but that doesn't mean we don't implement the direction of the issue there.

I'd be happy to replace the "yes" with "2.7" here, given that's our proxy for "forever", but I think "3.1" is wrong.

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