================
@@ -1,8 +1,16 @@
-// RUN: %clang_cc1 -fsyntax-only -verify %s -std=c++98 -Wc++11-compat
+// RUN: %clang_cc1 -fsyntax-only -verify %s -std=c++98 -Wc++11-compat
void f() {
auto int a; // expected-warning {{'auto' storage class specifier is
redundant and incompatible with C++11}}
int auto b; // expected-warning {{'auto' storage class specifier is
redundant and incompatible with C++11}}
auto c; // expected-warning {{C++11 extension}} expected-error {{requires an
initializer}}
static auto d = 0; // expected-warning {{C++11 extension}}
auto static e = 0; // expected-warning {{C++11 extension}}
}
+
+// typedef and auto storage-class-specifier cannot appear in the same
+// decl-specifier-seq ([dcl.stc] p1). This must be diagnosed in C++98 even
+// though 'auto int' (without typedef) is valid there.
+void g() {
+ typedef auto int t1; // expected-error {{cannot combine with previous
'typedef' declaration specifier}}
----------------
rahulana-quic wrote:
> In 22.x we're diagnosing that you cannot combine auto and int in C++98 mode.
> This patch restores that behavior
This patch does not restore that behavior because it does not really modify the
auto+int-without-typedef path in any way. I am also confused by what you said
about the 22.x behavior since I see [here](https://godbolt.org/z/Kxn7q1xWq)
that auto+int (no typedef) works without any issues.
> But we dropped the diagnostic which said 'auto' not allowed in typedef
We just emit the diagnostic at a different/earlier point but it is still an
equivalent diagnostic which correctly points out the problem:
```
<stdin>:1:20: error: cannot combine with previous 'typedef' declaration
specifier
1 | void g() { typedef auto int t1; }
| ^~~~
1 error generated.
```
> https://godbolt.org/z/xMrh3rzfv
In the current behavior, even though we emit `<source>:2:11: error: 'auto' not
allowed in typedef` we also emit `<source>:2:16: error: cannot combine with
previous 'auto' declaration specifier
` which is wrong because like you said, this should be allowed. After the
patch, the only diagnostic is what I pointed to above and is correct.
https://github.com/llvm/llvm-project/pull/210141
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits