================
@@ -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
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
