================
@@ -0,0 +1,22 @@
+// RUN: %clang_cc1 -fsyntax-only -verify -std=c++11 %s
+// RUN: %clang_cc1 -fsyntax-only -verify -std=c++14 %s
+// RUN: %clang_cc1 -fsyntax-only -verify -std=c++17 %s
+// RUN: %clang_cc1 -fsyntax-only -verify -std=c++20 %s
+// RUN: %clang_cc1 -fsyntax-only -verify -std=c++23 %s
+
+// Test that 'auto' cannot be combined with a type specifier in C++.
+void f() {
+ auto int x = 1; // expected-error {{'auto' cannot be combined with a
type specifier}}
----------------
zygoloid wrote:
You don't need to diagnose conflicts from `Finish`. Here's one approach:
* When consuming `auto`, treat it as specified by the underlying language
(either a type specifier or a storage class specifier).
* If we encounter a conflict between storage classes, if one of them is `auto`
and there is no type specifier yet, then set the type specifier to `auto` and
keep the other storage class as the "real" storage class specifier.
* In `Finish`, if there is a storage class of `auto` and no type specifier at
all, and we're in a language mode without "implicit int", then convert the
storage class to a type specifier.
Finally, if we have a type specifier of `TST_auto` in a language that doesn't
support it, then produce a warning.
In fact, looking at the `DeclSpec` implementation, we already do all of that.
So I'm a bit confused about what we're discussing.
https://github.com/llvm/llvm-project/pull/166004
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
