aaron.ballman added a comment.

In D133289#4489883 <https://reviews.llvm.org/D133289#4489883>, @aaron.ballman 
wrote:

> - `_Atomic auto x = 12;` is now something we should be accepting and deduce 
> as an `_Atomic int`

The committee is discussing this again on the reflectors. Thus far, almost 
everyone reads the standard the same way as GCC did with their implementation, 
which matches what I suggest above. However, there are folks who are claiming 
we should not be able to deduce the derived type because `_Atomic` forms an 
entirely new type and thus isn't actually a qualifier (and there are some words 
in the standard that could maybe be read as supporting that). The most 
conservative approach is to reject using `_Atomic auto` for right now so users 
don't build a reliance on it. Eventually WG14 will make a decision and we can 
relax that diagnostic then if we need to. Sorry for the confusion on this topic!



================
Comment at: clang/test/Sema/c2x-auto.c:119
+  return x;
+}
----------------
aaron.ballman wrote:
> Some additional test cases to consider:
> ```
> _Complex auto i = 12.0; // Should be rejected because _Complex is a type 
> specifier; however, 
>                         // when auto becomes a type specifier, this should be 
> accepted. GCC
>                         // rejects but if we end up accepting, I won't be sad 
> -- we'll need an
>                         // extension warning in that case though.
> 
> void foo(void) {
>   extern void foo(int a, int array[({ auto x = 12; x;})]); // This is a use 
> of `auto` within function prototype
>                                                            // scope, but 
> should still be accepted.
> }
> ```
The suggested comment I have isn't fully correct. It should be rejected because 
_Complex is a type specifier, but when auto becomes a type specifier, I think 
_Complex perhaps should still not deduce. Consider this analogous case (which 
could be a fun test case as well):
```
signed auto a = 1L;
```
`signed` is a type specifier as well, and this is not accepted in C++ (so we 
don't want to accept it in C either).


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D133289/new/

https://reviews.llvm.org/D133289

_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to