[C2X] N3007 Type inference for object definitions

[to268]

Summary

This patches implements the auto keyword from the N3007 standard specification.
This allows deducing the type of the variable like in C++

auto nb = 1;
auto chr = 'A';
auto str = "String";

The list of statements which allows the usage of auto:

• Basic variables declarations (int, float, double, char, char*...)
• Macros declaring a variable with the auto type

The list of statements which will not work with the auto keyword:

• auto arrays
• sizeof(), alignas()
• auto parameters, auto return type
• auto as a struct/typedef member
• uninitialized auto variables
• auto in an union
• auto as a enum type specifier
• auto casts
• auto in an compound literals

[to268]

I have fixed my CodeGen test with the windows platform.
(Linux uses an i64 for the long type instead windows is using an i32)

[to268]

Fixed DeclSpec.cpp formatting

[shafik]

The proposal has several nice tests and I don't they are all covered here e.g.:

{
  double a = 7;
  double b = 9;
  {
    double b = b * b;       // undefined, uses uninitialized variable without address

[to268]

I've added a test case with scopes.

[to268]

Also @aaron.ballman said me that he was thinking about maybe adding an extension to add support for auto in a function return or in a parameter list.

[cor3ntin]

In D133289#3773708, @to268 wrote:

Also @aaron.ballman said me that he was thinking about maybe adding an extension to add support for auto in a function return or in a parameter list.

I think extensions are best left to a separate pr, if at all.
Supporting deduced return type sounds fine, with a warning.
Supporting auto template parameters... Not so much, as it would in effect bring function templates, overloading and mangling into C... I don't think we want to go there.

I think we should consider supporting auto in older language modes though.

Or at least, improving the diagnostics for auto in older language modes.

type specifier missing, defaults to 'int'.

The probability that someone tries to use auto as a storage specifier and wants an implicit int at the same time is about 0.

[aaron.ballman]

This is awesome, thank you for working on it! @to268 and I had a really good discussion during my office hours and what we decided for next steps were:

0) Next time you upload a patch, please use -U9999 to give the patch more context for reviewers to see.

1. Need to handle function pointers: auto (*)(void) and void (*)(auto) should both be rejected - you may want to consider adding logic to Sema::BuildPointerType() to semantically restrict forming such a function pointer type.
2. Need a ton of random tests:

auto file_scope_1 = 12;
// This <might> be something we accept because the redundant storage class specifier is not
// specifying automatic storage duration due to the lack of a type specifier, or we might reject
// because of the redundant storage class specifier. I have a question out to the author to clarify.
auto auto file_scope_2 = 12;

void func(void) {
  int i;
  _Generic(i, auto : 0); // Should reject auto in an association
  _Alignof(auto); // Should also reject
  _Alignas(auto); // Should also reject


  auto j = ({ auto x = 12; x; }); // Should work, x and j should both be int
  auto auto k = 12; // 99% this is intended to be accepted; first `auto` is the storage class specifier, second `auto` is a redundant storage class specifier

  const int ci = 12;
  auto yup = ci;
  yup = 12; // Okay, the type of yup is int, not const int

  _Atomic(auto) atom1 = 12; // Should reject, asking WG14 about it
  _Atomic auto atom2 = 12; // Should also reject
}
`

It's worth noting that auto in C is a very, very strange beast. It's a storage-class-specifier, not a type-name. If there's a storage class specifier and NO TYPE NAME, then the type is inferred. So grammar productions that use type-name without also using storage-class-specifier should reject any use of auto because that's not a valid type name.

clang/test/C/C2X/n3007.c

6 ↗

(On Diff #458358)

Rather than include the system header, you should use _Alignas and _Alignof spellings.

45 ↗

(On Diff #458358)

Heh, this doesn't have much to do with structs. :-)

50 ↗

(On Diff #458358)

An additional tests here that's interesting is:

_Static_assert(_Generic(test_char_ptr, const char * : 1, char * : 2) == 2, "C is weird");

clang/test/Parser/c2x-auto.c

10

Should also test a structure member just to have the coverage.

clang/test/Sema/c2x-auto.c

4

Same suggestion here as above.

12–21

This seems to be duplicated from the parser tests -- there is only a need to test this once (and in each of these cases it seems to be a parsing restriction, so the tests should live in Parser).

33

This should have a FIXME comment -- we should produce a better diagnostic here. That we give an error is correct though!

C2x 6.5.2.5p4 specifies that compound literal is rewritten as if it were a declaration: SC typeof(T) ID = { IL }; (where SC is the storage class, T is the type, ID is a program-wide unique ID, and IL is the initializer list).

C2x 6.7.2.5p1 only allows typeof on an expression or a type-name, and type-name does not include auto as an option.

So the rewrite makes this invalid.

clang/www/c_status.html

1196

This should use class unreleased and specify Clang 16 instead of Yes ("Yes" basically means "we have no idea when we started supporting something, we've probably supported this forever")

[shafik]

clang/test/Sema/c2x-auto.c

50

When I made the comment about the example from the proposal, this was what I was thinking about.

[aaron.ballman]

FYI: regarding auto auto, I've heard back from the author of N3007 and the intent was to disallow this construct ("others" was meant to exclude auto and "except typedef" was meant to add onto the list of exclusions).

[aaron.ballman]

One thought that occurred to me is that the way C has this specified is awfully effectively the same way implicit int worked. It may be worth exploring a change to our implicit int functionality to instead generate an implicit auto type when in C2x mode.

[to268]

In D133289#3784042, @aaron.ballman wrote:

auto auto k = 12; // 99% this is intended to be accepted; first `auto` is the storage class specifier, second `auto` is a redundant storage class specifier

It seems that specifying auto twice isn't supported at the time being, so i think i should fix that too.

auto auto test = 12; // error: cannot combine with previous 'auto' declaration specifier

[aaron.ballman]

In D133289#3788655, @to268 wrote:

In D133289#3784042, @aaron.ballman wrote:

auto auto k = 12; // 99% this is intended to be accepted; first `auto` is the storage class specifier, second `auto` is a redundant storage class specifier

It seems that specifying auto twice isn't supported at the time being, so i think i should fix that too.

auto auto test = 12; // error: cannot combine with previous 'auto' declaration specifier

Yup! I just learned yesterday that the error there is correct and intended, at least according to the author of WG N3007.

[to268]

I've added more test cases, added a diagnostic when using auto in compound literals and advised fixes

[to268]

Also i have found that we don't parse the compound literal with the auto keyword correctly in ParseExpr.cpp between line 939 to 973 which is the beginning of Parser::ParseCastExpression(...)

int test_cl = (int){12};      // Compound literal is detected
auto test_cl2 = (auto){12};   // Compound literal is not detected

I've haven't dig deeper yet but maybe it's because we are not including auto when trying to guess if it's a compound literal due to the fact that auto is a storage-class-specifier

clang/test/Sema/c2x-auto.c

50

Do i need to treat shadowing when using auto as invalid?

[aaron.ballman]

In D133289#3784117, @aaron.ballman wrote:

One thought that occurred to me is that the way C has this specified is awfully effectively the same way implicit int worked. It may be worth exploring a change to our implicit int functionality to instead generate an implicit auto type when in C2x mode.

I've been thinking about this more and I'm starting to make myself a bit uncomfortable with the current approach, at least in terms of how we're handling it on the parsing side of things. I think it's reasonable for us to form an AutoType when we eventually get down to forming the type. But I'm uncomfortable with not modeling the language when parsing. e.g., I think we want to parse auto as a storage class specifier rather than a type specifier, and we want to rely on the lack of a type specifier coupled with use of auto as a storage class specifier to determine the situations where we want to infer a type. The resulting semantics should be basically equivalent, but this ensures that we're properly parsing as the language expects which helps us be forwards-compatible with future changes in C that build on top of this being a storage class specifier rather than a type.

Adding a few more reviewers for some extra opinions on this.

clang/include/clang/Basic/DiagnosticParseKinds.td

372

clang/lib/Parse/ParseExpr.cpp

1516

Why would this not be handled from Sema::ActOnCompoundLiteral()?

clang/test/C/C2x/n3007.c

8

Why? My reading of the grammar is that const auto is valid. const is a type-specifier-qualifier declaration-specifier, and auto is a storage-class-specifier declaration-specifier, and a declaration is allowed to use a sequence of declaration-specifiers.

16

clang/test/Sema/c2x-auto.c

50

You shouldn't need to do anything special there, I think. It should naturally fall out that you cannot use a variable in its own initialization. Note, you don't even need an inner scope for that: https://godbolt.org/z/EYa3fMxqx (example is compiled in C++ mode).

[shafik]

clang/test/Sema/c2x-auto.c

50

The scope of the identifier begins after its declarator so a is being used in it's own deduction which can not be.

e.g.

double a = 1.0;
  {
      int a = a*a; // undefined behavior a is used uninitialized within it's own initialization
  }

[to268]

I've fixed the diagnostic message and all of the bad TODOs comments from the Sema test.
I've explained in details why i'm only able to handle auto in compound literals.

In D133289#3784117, @aaron.ballman wrote:

One thought that occurred to me is that the way C has this specified is awfully effectively the same way implicit int worked. It may be worth exploring a change to our implicit int functionality to instead generate an implicit auto type when in C2x mode.

That's something is was trying to do a few weeks earlier, so i'll work on that too.

In D133289#3784117, @aaron.ballman wrote:

I've been thinking about this more and I'm starting to make myself a bit uncomfortable with the current approach, at least in terms of how we're handling it on the parsing side of things. I think it's reasonable for us to form an AutoType when we eventually get down to forming the type. But I'm uncomfortable with not modeling the language when parsing. e.g., I think we want to parse auto as a storage class specifier rather than a type specifier, and we want to rely on the lack of a type specifier coupled with use of auto as a storage class specifier to determine the situations where we want to infer a type. The resulting semantics should be basically equivalent, but this ensures that we're properly parsing as the language expects which helps us be forwards-compatible with future changes in C that build on top of this being a storage class specifier rather than a type.

I agree, that's a better approach to design it like that, i'll change my approach when i'll be able to generate an implicit auto.

[to268]

Here are all the details that i've said earlier

clang/lib/Parse/ParseExpr.cpp

1516

You're right, it's better to handle this in Sema::ActOnCompoundLiteral()
The problem is that right now, the usage of the auto keyword in a compound literal isn't parsed as a compound literal.
This compound literal is unable to reach Sema::ActOnCompoundLiteral() because the parser emits that it's an invalid expression.

To summarize, i'm unable to handle handle a compound literal that uses the auto keyword inside Sema::ActOnCompoundLiteral()
if it's never going to be called.

int test_ncl = (int){12};           // Parsed as a CL
auto test_cl = (auto){12};          // Not parsed as a CL and emits "expected expression"
/*
 * |-DeclStmt 0x562180ede8b0 <line:17:5, col:29>
 * | `-VarDecl 0x562180ede730 <col:5, col:28> col:9 test_ncl 'int' cinit
 * |   `-ImplicitCastExpr 0x562180ede898 <col:20, col:28> 'int' <LValueToRValue>
 * |     `-CompoundLiteralExpr 0x562180ede870 <col:20, col:28> 'int' lvalue
 * |       `-InitListExpr 0x562180ede828 <col:25, col:28> 'int'
 * |         `-IntegerLiteral 0x562180ede7b0 <col:26> 'int' 12
 * |-DeclStmt 0x562180ede970 <line:18:5, col:30>
 * | `-VarDecl 0x562180ede908 <col:5, col:10> col:10 invalid test_cl 'auto'
 * `-ReturnStmt 0x562180ede9a8 <line:19:5, col:12>
 *   `-IntegerLiteral 0x562180ede988 <col:12> 'int' 0
 */

1516

When we are parsing an expression between parentheses in Parser::ParseParenExpression() line 2972,
we are calling Parser::isTypeIdInParens() which when using C will return true if it's a type specifier,
which is not the case for the auto keyword.

Ultimately, we fall into the conditional block of Parser::ParseParenExpression() line 3191,
which will return an ExprError() (AKA: a parsing error).

This is why we are unable to forbid a compound literal using the auto keyword at the
Semantic Analysis stage and why this feature is not working out of the box in the first place.

clang/test/C/C2x/n3007.c

8

It's a mistake, i don't remember why i've added this comment in the first place and i've forgot his existence

[aaron.ballman]

clang/lib/Parse/ParseExpr.cpp

1516

When we are parsing an expression between parentheses in Parser::ParseParenExpression() line 2972,

we are calling Parser::isTypeIdInParens() which when using C will return true if it's a type specifier,
which is not the case for the auto keyword.

Ahhhh, that makes a lot of sense!

[to268]

This comment was removed by to268.

[to268]

Added a check to not diagnose a missing type specifier in C2x mode

[to268]

Reworked the parsing side of the patch

[to268]

Also i'm not sure if must add C2x to this condition just in case (falling back or add an assertion)

clang/lib/Sema/DeclSpec.cpp

1359

Do we need to include C2x just in case?

[aaron.ballman]

Thank you for the update to this!

clang/lib/Parse/ParseExpr.cpp

1516

I don't think this is quite right; I suspect we're going to need more complicated logic here. Consider a case like: (auto const){ 12 } or (auto *){ nullptr } where two tokens ahead is ) and not {. (Note, these type specifications can be pretty arbitrarily complex.)

Given that this is a temporary workaround for a lack of support for storage class specifiers in compound literals, perhaps another approach is to not try to catch uses in compound literals. Instead, we could add tests with FIXME comments to demonstrate the behavior we get with compound literals now, and when we do that storage class specifier work, we will (hopefully) break those tests and come back to make them correct.

1520–1521

This looks a bit less visually jarring to me (the indentation differences were distracting). WDYT?

clang/lib/Sema/DeclSpec.cpp

1359

I don't think so -- we're in a language where the type specifier *is* optional for C2x.

1367–1370

clang/test/C/C2x/n3007.c

14

I'd also like a test for:

_Atomic auto i = 12;
_Atomic(auto) j = 12;

_Atomic(int) foo(void);
auto k = foo(); // Do we get _Atomic(int) or just int?

37

I think this test should be _Alignas(auto) right?

41–42

I think other array cases we want to test are:

auto a = { 1 , 2 }; // Error
auto b = { 1, }; // OK
auto c = (int [3]){ 1, 2, 3 }; // OK

57

I'd also like to ensure we reject:

typedef auto (*fp)(void);
typedef void (*fp)(auto);

_Generic(0, auto : 1);

and we should ensure we properly get integer promotions:

short s;
auto a = s;
_Generic(a, int : 1);

and a test for use of an explicit pointer declarator (which is UB that we can define if we want to):

int a;
auto *ptr = &a; // Okay?
auto *ptr = a; // Error

clang/test/Sema/c2x-auto.c

28

This one should not be accepted -- the grammar productions for the initialization allow for {0} and {0,} but no more than one element in the braces.

[to268]

This is a status update of the patch.

clang/lib/Parse/ParseExpr.cpp

1516

I think it's better to make a test of the actual behavior than trying to correct this case.

1520–1521

That's better but i remember that clang-format has failed on that.

clang/test/C/C2x/n3007.c

14

The _Atomic qualifier is dropped so the type of k is an int

41–42

These statements are not working:

auto b = { 1, }; // Not valid
auto d = { 1 };  // Not valid

I think it's related to the compound literal.

57

> and we should ensure we properly get integer promotions:
>

short s;
auto a = s;
_Generic(a, int : 1);

I got the error controlling expression type 'short' not compatible with any generic association type so we don't promote from short to int

[to268]

Added test cases and added an explicit auto* diagnostic

[to268]

Removed compound literal diagnostic in ParseExpr

[aaron.ballman]

I spoke with @to268 during office hours about the current status of the NB comments for this feature in the C committee. For the moment, he's going to pause work on this patch until the C committee weighs in on whether auto is a type specifier or not. The committee meets the week of Jan 23, so we should have a better understanding of direction by the week of Jan 30. If the C committee turns auto into a type specifier, we may go back to the original implementation of this feature which exposes the C++ feature in C (and add diagnostics around the things that need to be constrained in C such as use in a function signature).

[tschuett]

It surprised me that there are no type inference messages? The type of this auto is double. I only found warnings of misuse of auto and codegen tests.

[aaron.ballman]

In D133289#4036529, @aaron.ballman wrote:

I spoke with @to268 during office hours about the current status of the NB comments for this feature in the C committee. For the moment, he's going to pause work on this patch until the C committee weighs in on whether auto is a type specifier or not. The committee meets the week of Jan 23, so we should have a better understanding of direction by the week of Jan 30. If the C committee turns auto into a type specifier, we may go back to the original implementation of this feature which exposes the C++ feature in C (and add diagnostics around the things that need to be constrained in C such as use in a function signature).

The minutes from last week's meeting aren't available yet, but I can give an update from my personal notes. Alex Gilding wrote a proposal to change the specification mechanisms away from "storage class specifier with no type specifier" and to an actual type specifier in WG14 N3076 (https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3076.pdf). WG14 briefly looked at the paper, but given how late in the cycle we are, we did not want to adopt new specification wording that is so drastically different from the existing wording. So we repaired the national body comments with WG14 N3079 (https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3079.htm) instead.

Does WG14 want something along the lines of N3076 in a future revision of the standard? 10 (for)/0 (against)/7 (abstain) -- consensus

So we now have sufficient support within WG14 for Clang to expose our C++ implementation of auto in C (with additional diagnostics for functionality C doesn't yet support like auto in function signatures) instead of implementing it from scratch as a weird storage class specifier/missing type specifier. However, we did make some other repairs to the feature so the current wording in the working draft (WG14 N3054) is not the latest. Specifically, we adopted US-122 and US-123 changes from WG14 N3079.

WG14 is expecting to have another week of meetings to work on NB comments (week of Feb 13) and we are expecting to have a second round of NB comments. I think it's okay for us to restart work on this patch now that we have a direction, but we might want to hold off on landing the patch until after we have a better idea of the final form of the specification. If there are no comments about it in CD2, then we're fine, but it's possible for CD2 to make breaking changes to the feature, so it's mostly about being aware of that situation.

[aaron.ballman]

In D133289#4037180, @tschuett wrote:

It surprised me that there are no type inference messages? The type of this auto is double. I only found warnings of misuse of auto and codegen tests.

Can you give a code example of what you expected to see a diagnostic for but aren't getting one?

[tschuett]

In D133289#4096588, @aaron.ballman wrote:

In D133289#4037180, @tschuett wrote:

It surprised me that there are no type inference messages? The type of this auto is double. I only found warnings of misuse of auto and codegen tests.

Can you give a code example of what you expected to see a diagnostic for but aren't getting one?

This is probably only for testing and not for Clang users:

auto Float = 3.0; // note that Float is a float

[to268]

Patch update: Reverting auto as a type specifier.
I am currently figuring out what behavior the auto keyword need to match.

[to268]

I have improved some diagnostics and i am now testing nullptr with auto.

[to268]

I have *hopefully* fixed my broken patch.
This is all the things in need to address:

auto str2[] = "string";
[[clang::overloadable]] auto test(auto x) { return x; }

and maybe retry to support auto in compound literals,
becaue i have seen heavy macro users that want compound literals to work.

I think it's safe to say that we will not support all features from N3076 in this patch.

[to268]

Fixed auto char arrays with explicit brackets

c
auto foo[] = "bar";

[aaron.ballman]

Thank you for the continued work on this! In general, I think the test coverage should verify the deduced type information more often. e.g., if we accept the code, there should probably be a static_assert nearby that ensures the deduced type is what we'd expect.

I applied the patch locally and tried out various things, and here's some test coverage I think we're lacking.

// Important: these two declarations are at file scope, we're testing that the storage
// class specifier is ignored because we're deducing the type.
auto i = 12; // Ok, deduces int
auto j = 12ull; // Ok, deduces unsigned long long

// This is testing whether storage specifier order matters:
void func() {
  const auto static i = 12; // Ok, static variable of type const int
}

In D133289#4279054, @to268 wrote:

I have *hopefully* fixed my broken patch.
This is all the things in need to address:

auto str2[] = "string";
[[clang::overloadable]] auto test(auto x) { return x; }

and maybe retry to support auto in compound literals,
becaue i have seen heavy macro users that want compound literals to work.

I think it's safe to say that we will not support all features from N3076 in this patch.

My testing of your patch suggests those aren't issues left to address (perhaps). e.g.,

auto test[] = "foo";
static_assert(_Generic(test, char * : 1, default : 0));

this matches what I'd expect (no warning, no failed assertion; string literals have type char [] in C, not const char[].

My testing of __attribute__((overloadable)) with your patch is that we currently reject use of auto in those functions. I think that's good initial behavior -- if we want to allow auto there, that's probably better left to a follow-up patch anyway because I'd expect there to be some debate around whether that's a good idea or not.

As for compound literals, I think we've determined they're not supported by C currently.

clang/test/C/C2x/n3007.c

21

This diagnostic is incorrect -- I believe this code should be accepted.

22

This diagnostic is correct.

32–33

We should test that the types match our expectations:

double A[3] = { 0 };
auto pA = A; // pA is double * due to array decay on A
static_assert(_Generic(pA, double * : 1, default : 0));
auto qA = &A; // qA is double (*)[3]
static_assert(_Generic(qA, double (*)[3] : 1, default : 0));

47

I think this would make it more clear that what's being tested is the _Alignas behavior.

57–58

This should now be resolved in N3096 so the FIXME comment can be removed.

67

This is awfully close to the examples from the paper (6.7.9p3):

auto p1 = (struct { int a; } *)0; // error expected

struct s;
auto p2 = (struct s { int a; } *)0; // error expected

They are expected to be diagnosed due to changes in N3006 (underspecified object definitions), so I think it's fine to add a FIXME comment with the test cases instead of trying to also implement N3006 at the same time. We currently list that as unknown in our status page, but I think it's clearly a no now.

101

No longer accurate (see comments below), so I think this FIXME comment can be removed.

107–108

I'd like to see a test that passes -pedantic which diagnoses these declarations with a warning about accepting this code being a Clang extension. (The standard requires we support auto ident = expr; but leaves other declarator pieces up to the implementation.)

Note, 6.7.9p2 made this implementation-defined behavior, so we also need to add some documentation to meet that requirement.

clang/test/Parser/c2x-auto.c

47–52

The C2x diagnostics here are kind of mean because if you give an initializer, we then reject the code anyway. If possible, it'd be nice to reject this for use of auto with an array declarator rather than the lack of an initializer.

79–82

This is tested below with a more clear test.

clang/test/Sema/c2x-auto.c

27–28

This FIXME is no longer accurate, I think it's not clear whether we should accept or reject this code from reading the standard, but I'm now thinking we should reject it for two reasons: 1) 6.7.9p1 says "A declaration for which the type is inferred shall contain the storage-class specifier auto", but a compound literal is not a declaration, it's an expression. What's more, it doesn't have a direct declarator or an equals sign as specified in p2. 2) GCC rejects: https://godbolt.org/z/K8sqr9qTT

[to268]

I have updated and fixed all minors comments about the test cases.
I have added the diagnostic to warn users about using a Clang extension when declaring an explicit auto* in pedantic mode.
I need to debug more about the two remaining diagnostics to fix:

• Wrong diagnostic when using the _Atomic attribute
• Misleading diagnostic where it should say that auto is not allowed but says that [...] requires an initializer.

[to268]

I have fixed the misleading diagnostic with auto array declarations.
The diagnostics now says that 'auto' is not allowed in array declarations.

I am not sure with the way i have currently implemented it in SemaDecl.cpp, maybe it can be done in a cleaner way.

[to268]

Minor code reformatting

[aaron.ballman]

Thank you for your patience while WG14 finalized the feature and I wrapped my head around the moving parts involved. I think this is shaping up nicely, but there's still some diagnostic issues. The biggest ones are:

• We should have an extension warning for array use with string literals auto str[] = "testing";
• We should be careful about testing underspecified declarations in a way that give the impression they're an extension, so we should sprinkle more fixme comments around the tests
• _Atomic auto x = 12; is now something we should be accepting and deduce as an _Atomic int

I think there's a typo in the patch summary:

auto in an compound statement

I think you mean "as the type of a compound literal"?

clang/include/clang/Basic/DiagnosticSemaKinds.td

240–242 ↗

(On Diff #537422)

I think we'll need this diagnostic for more than just * in a declaration. Consider a case like:

auto val = (struct X { int y; }){ 0 };

accepting this is also an extension because it declares y, which is not an "ordinary" identifier. See 6.7.9p2-3

Also, because this is about the syntax used, I think this might be a diagnostic that should live in DiagnosticParseKinds.td (but maybe it's correct here, I've not reviewed enough yet to see).

2417 ↗

(On Diff #537422)

I'm surprised to see decltype(auto) here as decltype isn't a keyword in C so it'd be invalid syntax; let's switch it to something that makes it obvious that we should never issue that particular part of the diagnostic in C.

clang/lib/Sema/SemaDecl.cpp

12684–12685 ↗

(On Diff #537422)

Comment can be re-flowed to 80 columns and the comment should end in a period. (Weirdly, Phabricator isn't letting me suggest edits just within this file.)

12687–12688 ↗

(On Diff #537422)

This can switch to using !isa_and_present<StringLiteral, InitListExpr>(Init) (the _and_nonnull variant is quietly deprecated).

12690 ↗

(On Diff #537422)

Please add a /* */ comment before 23 detailing what that magic number will be printing.

clang/lib/Sema/SemaTemplateDeduction.cpp

4780 ↗

(On Diff #537422)

4789–4792 ↗

(On Diff #537422)

I think this diagnostic should happen from the parser rather then when determining the concrete type; that ensures consistent diagnosis of the syntax regardless of whether we needed to deduce the type or not.

clang/test/C/C2x/n3007.c

7–23

Adding one more test case for restrict-qualified pointers.

26

What we finally landed on in WG14 is that this should be accepted. In this form, _Atomic is being used as a type qualifier (not a type specifier), and 6.7.9p2 explicitly talks about qualifiers: "The inferred type of the declared object is the type of the assignment expression after lvalue, array to pointer or function to pointer conversion, additionally qualified by qualifiers and amended by attributes as they appear in the declaration specifiers, if any."

So this should form an _Atomic int initialized to the value 12, and that matches GCC's behavior: https://godbolt.org/z/s468s86z6

33

The first error on this line isn't helpful; the second error is the only one I'd expect to see here.

64

To make it clear that use of auto within sizeof is the issue, not the initialization itself.

82–85

Might need to re-flow the comment as well.

103

This should also get the "is a clang extension" warning because the declarators include [].

117

clang/test/CodeGen/auto.c

16

20–23

I'd like to see a sema test for this:

auto t = ({
  auto b = 12;
  b;
)};
_Generic(t, int : 1);

clang/test/Parser/c2x-auto.c

72–73

98

123

This one should be fixed and accepted.

125

I'd like to see parsing tests for:

auto ident [[clang::annotate("this works")]] = 12; // No diagnostic expected

We should also add a test that this C++'ism doesn't work in C:

int a = auto(0);

clang/test/Sema/c2x-auto.c

75

This should also get an extension warning.

120

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

clang/www/c_status.html

1182

This can be committed as an NFC change separate from this review, given that it's slightly orthogonal.

[aaron.ballman]

In 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!

clang/test/Sema/c2x-auto.c

120

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

[to268]

Thank you for your feedback @aaron.ballman!
I really appreciate that you are pointing out all my formatting mistakes, and giving me more guidelines.
The direction of the patch is clearer now.

In D133289#4489883, @aaron.ballman wrote:

I think there's a typo in the patch summary:

auto in an compound statement

I think you mean "as the type of a compound literal"?

Yes i was a mistake, I have edited the summary to fix that typo.

In D133289#4489883, @aaron.ballman wrote:

• We should have an extension warning for array use with string literals auto str[] = "testing";

This makes sense, since auto arrays are prohibited in the standard.

In D133289#4497901, @aaron.ballman wrote:

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!

I was wondering about the support of _Atomic auto, i will add new error diagnostic to prohibit _Atomic auto, thank you for addressing that topic!

[to268]

Added recommendations from @aaron.ballman.
Adjusting diagnostic messages still need to be done.

clang/test/Sema/c2x-auto.c

120

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

I think you made a mistake there by using the same function name as the outer one.

[to268]

This update is mostly a followup of a change upstream that consist of renaming all C2x references to C23.

[to268]

This updates fixes the _Atomic auto diagnostic, the previous diagnostic was confusing since it was referencing a C++ feature (std::is_trivially_copyable).
I have a few diagnostic issues remaining, some parts need to take place as earlier in the Parsing stage and be diagnosed in the Sema stage.
PS: I'll migrate this patch to GH at the end of September if I need to.

[to268]

Fixed the initializer list diagnotic

[to268]

I need thoughts about this.

clang/lib/Sema/SemaTemplateDeduction.cpp

4805–4806 ↗

(On Diff #557115)

It feels wrong to check if it's not C++ and changing the diagnostic if we are in C, I only emit the fixed diagnostic in C23 mode for now.

[aaron.ballman]

I spotted some minor issues, but this LGTM for the initial implementation. Thank you for all your effort on this project!!

There are some outstanding issues that should be handled in a follow up, however:

void foo() {
   auto l = (struct S { int x, y; }){ 1, 2 }; // Underspecified declaration, should diagnose

  _Atomic int i;
  _Static_assert(_Generic(&i, _Atomic auto *: 1)); // Gets two errors instead of just 1

  auto int i = 12; // At local and file scope, now gives: warning: 'auto' storage class specifier is not permitted in C++11, and will not be supported in future releases

  auto __attribute__((mode(HI))) i = 12; // Gives confused diagnostics, but GCC also doesn't accept currently either
  _Static_assert(_Generic(i, short : 1)); // But if we accepted the above, this should pass. 
}

but these all seem minor enough to be handled in follow-up work.

Do you need me to land this on your behalf? If so, I can fix up the NFC changes I found for you, but what email address would you like me to use for patch attribution?

clang/lib/Sema/DeclSpec.cpp

1368–1369

clang/lib/Sema/SemaDecl.cpp

12869 ↗

(On Diff #557115)

/*in array decl*/ instead of here

clang/test/C/C2x/n3007.c

33

To be clear, I mean this example should have one diagnostic instead of two:

_Static_assert(_Generic(&i, _Atomic auto *: 1)); // expected-error {{_Atomic cannot be applied to type 'auto' in C23}} \
                                                    expected-error {{'auto' not allowed here}}

clang/test/Sema/c2x-auto.c

111–112

[to268]

Do you need me to land this on your behalf? If so, I can fix up the NFC changes I found for you, but what email address would you like me to use for patch attribution?

It is probably the best thing to do, and yes I need you to land this on your behalf. Guillot Tony <[e-mail]>

There are some outstanding issues that should be handled in a follow up

I will start to work on these issues, when the patch has been landed.

Thank you for the review!

[to268]

Fix arm buildbot issues

clang/include/clang/Basic/DiagnosticParseKinds.td

 def ext_auto_storage_class : ExtWarn<
   "'auto' storage class specifier is not permitted in C++11, and will not "
   "be supported in future releases">, InGroup<DiagGroup<"auto-storage-class">>;
 def ext_decltype_auto_type_specifier : ExtWarn<
   "'decltype(auto)' type specifier is a C++14 extension">, InGroup<CXX14>;
 def warn_cxx11_compat_decltype_auto_type_specifier : Warning<
   "'decltype(auto)' type specifier is incompatible with C++ standards before "
   "C++14">, InGroup<CXXPre14Compat>, DefaultIgnore;
+def err_c2x_auto_compound_literal_not_allowed: Error<
+  "'auto' is not allowed in a compound literal">;
 def ext_auto_type : Extension<
   "'__auto_type' is a GNU extension">,
   InGroup<GNUAutoType>;
 def warn_c2x_compat_typeof_type_specifier : Warning<
   "'%select{typeof|typeof_unqual}0' is incompatible with C standards before "
   "C2x">, InGroup<CPre2xCompat>, DefaultIgnore;
 def ext_for_range : ExtWarn<
   "range-based for loop is a C++11 extension">, InGroup<CXX11>;

clang/lib/Parse/ParseDecl.cpp

while (true) {
     case tok::kw_static:
       if (DS.getThreadStorageClassSpec() == DeclSpec::TSCS___thread)
         Diag(Tok, diag::ext_thread_before) << "static";
       isInvalid = DS.SetStorageClassSpec(Actions, DeclSpec::SCS_static, Loc,
                                          PrevSpec, DiagID, Policy);
       isStorageClass = true;
       break;
     case tok::kw_auto:
-      if (getLangOpts().CPlusPlus11) {
+      if (getLangOpts().CPlusPlus11 || getLangOpts().C2x) {
         if (isKnownToBeTypeSpecifier(GetLookAheadToken(1))) {
           isInvalid = DS.SetStorageClassSpec(Actions, DeclSpec::SCS_auto, Loc,
                                              PrevSpec, DiagID, Policy);
           if (!isInvalid)
             Diag(Tok, diag::ext_auto_storage_class)
               << FixItHint::CreateRemoval(DS.getStorageClassSpecLoc());
         } else
           isInvalid = DS.SetTypeSpecType(DeclSpec::TST_auto, Loc, PrevSpec,

clang/lib/Parse/ParseExpr.cpp

if (isStartOfObjCClassMessageMissingOpenBracket()) {
 
       ConsumeAnnotationToken();
       Res = ParseObjCMessageExpressionBody(SourceLocation(), SourceLocation(),
                                            Ty.get(), nullptr);
       break;
     }
     [[fallthrough]];
 
+  case tok::kw_auto: {
+    // We are trying to detect if the second next token is '{'
+    // in this case it's must be a compound literal
+    // This is a temporary fix while we don't support C2x 6.5.2.5p4
+    if (getLangOpts().C2x && GetLookAheadToken(2).getKind() == tok::l_brace) {
+      Diag(Tok, diag::err_c2x_auto_compound_literal_not_allowed);
+      return ExprError();
+    }
+  }
+    [[fallthrough]];
+
   case tok::annot_decltype:
   case tok::kw_char:
   case tok::kw_wchar_t:
   case tok::kw_char8_t:
   case tok::kw_char16_t:
   case tok::kw_char32_t:
   case tok::kw_bool:
   case tok::kw_short:
   case tok::kw_int:
   case tok::kw_long:
   case tok::kw___int64:
   case tok::kw___int128:
   case tok::kw__ExtInt:
   case tok::kw__BitInt:
   case tok::kw_signed:
   case tok::kw_unsigned:
   case tok::kw_half:
   case tok::kw_float:
   case tok::kw_double:
   case tok::kw___bf16:
   case tok::kw__Float16:
   case tok::kw___float128:
   case tok::kw___ibm128:
   case tok::kw_void:
-  case tok::kw_auto:
   case tok::kw_typename:
   case tok::kw_typeof:
   case tok::kw___vector:
 #define GENERIC_IMAGE_TYPE(ImgType, Id) case tok::kw_##ImgType##_t:
 #include "clang/Basic/OpenCLImageTypes.def"
   {
     if (!getLangOpts().CPlusPlus) {
       Diag(Tok, diag::err_expected_expression);

clang/lib/Sema/DeclSpec.cpp

default:
       ThreadStorageClassSpecLoc = SourceLocation();
     }
   }
 
   // If no type specifier was provided and we're parsing a language where
   // the type specifier is not optional, but we got 'auto' as a storage
   // class specifier, then assume this is an attempt to use C++0x's 'auto'
   // type specifier.
   if (S.getLangOpts().CPlusPlus &&
       TypeSpecType == TST_unspecified && StorageClassSpec == SCS_auto) {
     TypeSpecType = TST_auto;
     StorageClassSpec = SCS_unspecified;
     TSTLoc = TSTNameLoc = StorageClassSpecLoc;
     StorageClassSpecLoc = SourceLocation();
   }
   // Diagnose if we've recovered from an ill-formed 'auto' storage class
-  // specifier in a pre-C++11 dialect of C++.
-  if (!S.getLangOpts().CPlusPlus11 && TypeSpecType == TST_auto)
+  // specifier in a pre-C++11 dialect of C++ or in a C2X dialect of C.
+  if ((!S.getLangOpts().CPlusPlus11 && !S.getLangOpts().C2x) &&
+      TypeSpecType == TST_auto)
     S.Diag(TSTLoc, diag::ext_auto_type_specifier);
   if (S.getLangOpts().CPlusPlus && !S.getLangOpts().CPlusPlus11 &&
       StorageClassSpec == SCS_auto)
     S.Diag(StorageClassSpecLoc, diag::warn_auto_storage_class)
       << FixItHint::CreateRemoval(StorageClassSpecLoc);
   if (TypeSpecType == TST_char8)
     S.Diag(TSTLoc, diag::warn_cxx17_compat_unicode_type);
   else if (TypeSpecType == TST_char16 || TypeSpecType == TST_char32)
     S.Diag(TSTLoc, diag::warn_cxx98_compat_unicode_type)

clang/lib/Sema/SemaType.cpp

if (S.getLangOpts().isImplicitIntRequired()) {
       } else if (S.getLangOpts().getOpenCLCompatibleVersion() >= 200 &&
                  DS.isTypeSpecPipe()) {
         S.Diag(DeclLoc, diag::err_missing_actual_pipe_type)
             << DS.getSourceRange();
         declarator.setInvalidType(true);
       } else {
         assert(S.getLangOpts().isImplicitIntAllowed() &&
                "implicit int is disabled?");
+
+        // We only diagnose that a type specifier is missing
+        // unless with the C2x standard
+        if (!S.getLangOpts().C2x) {
           S.Diag(DeclLoc, diag::ext_missing_type_specifier)
               << DS.getSourceRange()
               << FixItHint::CreateInsertion(DS.getBeginLoc(), "int");
         }
       }
+    }
 
     [[fallthrough]];
   case DeclSpec::TST_int: {
     if (DS.getTypeSpecSign() != TypeSpecifierSign::Unsigned) {
       switch (DS.getTypeSpecWidth()) {
       case TypeSpecifierWidth::Unspecified:
         Result = Context.IntTy;
         break;

clang/test/C/C2x/n3007.c

+// RUN: %clang_cc1 -std=c2x -verify %s
+
+/* WG14 N3007: Yes
+ * Type Inference for object definitions
+ */
+void test_qualifiers(int x, const int y) {
+  const auto a = x;
+  auto b = y;
+  static auto c = 1UL;
+  int* pa = &a; // expected-warning {{initializing 'int *' with an expression of type 'const int *' discards qualifiers}}
+  const int* pb = &b;
+  int* pc = &c; // expected-warning {{incompatible pointer types initializing 'int *' with an expression of type 'unsigned long *'}}
+
+  const int ci = 12;
+  auto yup = ci;
+  yup = 12;
+}
+
+void test_double(void) {
+  double A[3] = { 0 };
+  auto pA = A;
+  auto qA = &A;
+  auto pi = 3.14;
+}
+
+int test_auto_param(auto a) { // expected-error {{'auto' not allowed in function prototype}}
+  return (int)(a * 2);
+}
+
+auto test_auto_return(float a, int b) { // expected-error {{'auto' not allowed in function return type}}
+  return ((a * b) * (a / b));
+}
+
+void test_sizeof_alignas(void) {
+  auto auto_size = sizeof(auto);  // expected-error {{expected expression}}
+  _Alignas(4) auto b[4];          // expected-error {{'b' declared as array of 'auto'}}
+}
+
+void test_arrary(void) {
+  auto a[4];          // expected-error {{'a' declared as array of 'auto'}}
+  auto b[] = {1, 2};  // expected-error {{'b' declared as array of 'auto'}}
+}
+
+void test_structs(void) {
+  auto a = (struct { int a; } *)0;
+  struct B { auto b; };   // expected-error {{'auto' not allowed in struct member}}
+}
+
+void test_misc(void) {
+  auto something;                 // expected-error {{declaration of variable 'something' with deduced type 'auto' requires an initializer}}
+  auto test_char = 'A';
+  auto test_char_ptr = "test";
+  auto auto_size = sizeof(auto);  // expected-error {{expected expression}}
+  typedef auto auto_type;         // expected-error {{'auto' not allowed in typedef}}
+
+  _Static_assert(_Generic(test_char_ptr, const char * : 1, char * : 2) == 2, "C is weird");
+}
+
+void test_loop(void) {
+  auto j = 4;
+  for (auto i = j; i < 2 * j; i++);
+}
+
+#define AUTO_MACRO(_NAME, ARG, ARG2, ARG3) \
+  auto _NAME = ARG + (ARG2 / ARG3);
+
+// This macro should only work with integers due to the usage of binary operators
+#define AUTO_INT_MACRO(_NAME, ARG, ARG2, ARG3) \
+  auto _NAME = (ARG ^ ARG2) & ARG3;
+
+int test_macros(int in_int) {
+  auto a = in_int + 1;
+  AUTO_MACRO(b, 1.3, 2.5f, 3);
+  AUTO_INT_MACRO(c, 64, 23, 0xff);
+  AUTO_INT_MACRO(not_valid, 51.5, 25, 0xff); // expected-error {{invalid operands to binary expression ('double' and 'int')}}
+  return (a + (int)b) - c;
+}

clang/test/CodeGen/auto.c

+// RUN: %clang_cc1 -std=c2x -emit-llvm %s -o - | FileCheck %s
+
+void basic_types(void) {
+    auto nb = 4;        // CHECK: %nb = alloca i32, align 4
+    auto dbl = 4.3;     // CHECK: %dbl = alloca double, align 8
+    auto lng = 4UL;     // CHECK: %lng = alloca i{{32|64}}, align {{4|8}}
+    auto bl = true;     // CHECK: %bl = alloca i8, align 1
+    auto chr = 'A';     // CHECK: %chr = alloca i32, align 4
+    auto str = "Test";  // CHECK: %str = alloca ptr, align 8
+}
+
+void misc_declarations(void) {
+  auto strct_ptr = (struct { int a; } *)0;  // CHECK: %strct_ptr = alloca ptr, align 8
+  auto int_cl = (int){13};                  // CHECK: %int_cl = alloca i32, align 4
+  auto double_cl = (double){2.5};           // CHECK: %double_cl = alloca double, align 8
+
+  auto se = ({                              // CHECK: %se = alloca i32, align 4
+    auto snb = 12;                          // CHECK: %snb = alloca i32, align 4
+    snb;
+  });
+}
+
+void loop(void) {
+  auto j = 4;                       // CHECK: %j = alloca i32, align 4
+  for (auto i = j; i < 2 * j; i++); // CHECK: %i = alloca i32, align 4
+}
+
+#define AUTO_MACRO(_NAME, ARG, ARG2, ARG3) \
+  auto _NAME = ARG + (ARG2 / ARG3);
+
+#define AUTO_INT_MACRO(_NAME, ARG, ARG2, ARG3) \
+  auto _NAME = (ARG ^ ARG2) & ARG3;
+
+int macros(int in_int) {
+  auto a = in_int + 1;              // CHECK: %a = alloca i32, align 4
+  AUTO_MACRO(b, 1.3, 2.5f, 3);      // CHECK: %b = alloca double, align 8
+  AUTO_INT_MACRO(c, 64, 23, 0xff);  // CHECK: %c = alloca i32, align 4
+  return (a + (int)b) - c;          // CHECK: ret i32 %sub
+}

clang/test/Parser/c2x-auto.c

+// RUN: %clang_cc1 -fsyntax-only -verify=expected,c2x -std=c2x %s
+// RUN: %clang_cc1 -fsyntax-only -verify=expected,c17 -std=c17 %s
+
+#define AUTO_MACRO(_NAME, ARG, ARG2, ARG3) \
+  auto _NAME = ARG + (ARG2 / ARG3);
+
+struct S {
+    int a;
+    auto b;       // c2x-error {{'auto' not allowed in struct member}} \
+                     c17-error {{type name does not allow storage class to be specified}} \
+                     c17-error {{type specifier missing, defaults to 'int'; ISO C99 and later do not support implicit int}}
+    union {
+      char c;
+      auto smth;  // c2x-error {{'auto' not allowed in union member}} \
+                     c17-error {{type name does not allow storage class to be specified}} \
+                     c17-error {{type specifier missing, defaults to 'int'; ISO C99 and later do not support implicit int}}
+    } u;
+};
+
+enum E : auto { // c2x-error {{'auto' not allowed here}} \
+                   c17-error {{expected a type}} \
+                   c17-error {{type name does not allow storage class to be specified}}
+  One,
+  Two,
+  Tree,
+};
+
+auto basic_usage(auto auto) {   // c2x-error {{'auto' not allowed in function prototype}} \
+                                   c2x-error {{'auto' not allowed in function return type}} \
+                                   c2x-error {{cannot combine with previous 'auto' declaration specifier}} \
+                                   c17-error {{invalid storage class specifier in function declarator}} \
+                                   c17-error {{illegal storage class on function}} \
+                                   c17-warning {{duplicate 'auto' declaration specifier}} \
+                                   c17-warning {{omitting the parameter name in a function definition is a C2x extension}} \
+                                   c17-error {{type specifier missing, defaults to 'int'; ISO C99 and later do not support implicit int}} \
+                                   c17-error {{type specifier missing, defaults to 'int'; ISO C99 and later do not support implicit int}}
+
+  auto = 4;                     // expected-error {{expected identifier or '('}}
+
+  auto a = 4;                   // c17-error {{type specifier missing, defaults to 'int'; ISO C99 and later do not support implicit int}}
+
+  auto auto aa = 12;            // c2x-error {{cannot combine with previous 'auto' declaration specifier}} \
+                                   c17-warning {{duplicate 'auto' declaration specifier}} \
+                                   c17-error {{type specifier missing, defaults to 'int'; ISO C99 and later do not support implicit int}}
+
+  auto b[4];                    // c2x-error {{'b' declared as array of 'auto'}} \
+                                   c17-error {{type specifier missing, defaults to 'int'; ISO C99 and later do not support implicit int}}
+
+  auto array[auto];             // expected-error {{expected expression}} \
+                                   c2x-error {{declaration of variable 'array' with deduced type 'auto' requires an initializer}} \
+                                   c17-error {{type specifier missing, defaults to 'int'; ISO C99 and later do not support implicit int}}
+
+  AUTO_MACRO(auto, 1, 2, 3);    // c2x-error {{cannot combine with previous 'auto' declaration specifier}} \
+                                   expected-error {{expected identifier or '('}} \
+                                   c17-warning {{duplicate 'auto' declaration specifier}}
+
+  auto c = (auto)a;             // expected-error {{expected expression}} \
+                                   c17-error {{type specifier missing, defaults to 'int'; ISO C99 and later do not support implicit int}}
+  return c;
+}
+
+void structs(void) {
+  struct s_auto { auto a; };            // c2x-error {{'auto' not allowed in struct member}} \
+                                           c17-error {{type name does not allow storage class to be specified}} \
+                                           c17-error {{type specifier missing, defaults to 'int'; ISO C99 and later do not support implicit int}}
+
+  auto s_int = (struct { int a; } *)0;  // c17-error {{incompatible pointer to integer conversion initializing 'int' with an expression of type}} \
+                                           c17-error {{type specifier missing, defaults to 'int'; ISO C99 and later do not support implicit int}}
+
+  typedef auto auto_type;               // c2x-error {{'auto' not allowed in typedef}} \
+                                           c17-error {{cannot combine with previous 'typedef' declaration specifier}} \
+                                           c17-error {{type specifier missing, defaults to 'int'; ISO C99 and later do not support implicit int}}
+}
+
+void sizeof_alignas(void) {
+  auto auto_size = sizeof(auto);  // expected-error {{expected expression}} \
+                                     c17-error {{type specifier missing, defaults to 'int'; ISO C99 and later do not support implicit int}}
+
+  _Alignas(4) auto b[4];          // c2x-error {{'b' declared as array of 'auto'}} \
+                                     c17-error {{type specifier missing, defaults to 'int'; ISO C99 and later do not support implicit int}}
+}
+
+void generic_alignof_alignas(void) {
+  int g;
+  _Generic(g, auto : 0);  // c2x-error {{'auto' not allowed here}} \
+                             c17-error {{expected a type}} \
+                             c17-error {{type name does not allow storage class to be specified}}
+
+  _Alignof(auto);         // expected-error {{expected expression}} \
+                             expected-warning {{'_Alignof' applied to an expression is a GNU extension}}
+
+  _Alignas(auto);         // expected-error {{expected expression}} \
+                             expected-warning {{declaration does not declare anything}}
+}
+
+void test_function_pointers(void) {
+    extern auto auto_ret_func(void);    // c2x-error {{'auto' not allowed in function return type}} \
+                                           c17-error {{cannot combine with previous 'extern' declaration specifier}} \
+                                           c17-error {{type specifier missing, defaults to 'int'; ISO C99 and later do not support implicit int}}
+
+    extern void auto_param_func(auto);  // c2x-error {{'auto' not allowed in function prototype}} \
+                                           c17-error {{invalid storage class specifier in function declarator}} \
+                                           c17-error {{type specifier missing, defaults to 'int'; ISO C99 and later do not support implicit int}}
+
+    auto (auto_ret_func)(void);         // c2x-error {{'auto' not allowed in function return type}} \
+                                           c17-error {{illegal storage class on function}} \
+                                           c17-error {{type specifier missing, defaults to 'int'; ISO C99 and later do not support implicit int}}
+
+    void (auto_param_func)(auto);       // c2x-error {{'auto' not allowed in function prototype}} \
+                                           c17-error {{invalid storage class specifier in function declarator}} \
+                                           c17-error {{type specifier missing, defaults to 'int'; ISO C99 and later do not support implicit int}}
+}
+
+void atomic(void) {
+    _Atomic(auto) atom1 = 12; // c2x-error {{'auto' not allowed here}} \
+                                 c2x-error {{a type specifier is required for all declarations}} \
+                                 c17-error {{expected a type}} \
+                                 c17-error {{type name does not allow storage class to be specified}} \
+                                 c17-error {{type specifier missing, defaults to 'int'; ISO C99 and later do not support implicit int}}
+
+    _Atomic auto atom2 = 12;  // c2x-error {{_Atomic cannot be applied to type 'auto' which is not trivially copyable}} \
+                                 c17-error {{type specifier missing, defaults to 'int'; ISO C99 and later do not support implicit int}}
+}

clang/test/Sema/c2x-auto.c

+// RUN: %clang_cc1 -fsyntax-only -verify -std=c2x %s
+
+void test_basic_types(void) {
+  auto undefined;                 // expected-error {{declaration of variable 'undefined' with deduced type 'auto' requires an initializer}}
+  auto auto_int = 4;
+  auto auto_long = 4UL;
+}
+
+void test_sizeof_typeof(void) {
+  auto auto_size = sizeof(auto);  // expected-error {{expected expression}}
+  typeof(auto) tpof = 4;          // expected-error {{expected expression}}
+}
+
+void test_casts(void) {
+  auto int_cast = (int)(4 + 3);
+  auto double_cast = (double)(1 / 3);
+  auto long_cast = (long)(4UL + 3UL);
+  auto auto_cast = (auto)(4 + 3); // expected-error {{expected expression}}
+}
+
+void test_compound_literral(void) {
+  auto int_cl = (int){13};
+  auto double_cl = (double){2.5};
+
+  // FIXME: This should be accepted per C2x 6.5.2.5p4
+  auto auto_cl = (auto){13};  // expected-error {{'auto' is not allowed in a compound literal}}
+  auto array[] = { 1, 2, 3 }; // expected-error {{'array' declared as array of 'auto'}}
+}
+
+void test_qualifiers(int x, const int y) {
+  const auto a = x;
+  auto b = y;
+  static auto c = 1UL;
+  int* pa = &a; // expected-warning {{initializing 'int *' with an expression of type 'const int *' discards qualifiers}}
+  const int* pb = &b;
+  int* pc = &c; // expected-warning {{incompatible pointer types initializing 'int *' with an expression of type 'unsigned long *'}}
+}
+
+void test_scopes(void) {
+  {
+    auto a = 7;
+    auto b = 9;
+    auto c = a + b;
+  }
+  {
+    auto d = a * b;   // expected-error {{use of undeclared identifier 'a'}} \
+                         expected-error {{use of undeclared identifier 'b'}}
+    {
+      auto e = d + c; // expected-error {{use of undeclared identifier 'c'}}
+    }
+  }
+}

clang/www/c_status.html

</tr>
     <tr>
       <td>Comma ommission and deletion (__VA_OPT__)</td>
       <td><a href="https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3033.htm">N3033</a></td>
       <td class="unknown" align="center">Unknown</td>
     </tr>
     <tr>
       <td>Underspecified object definitions</td>
       <td><a href="https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3006.htm">N3006</a></td>
       <td class="unknown" align="center">Unknown</td>
     </tr>
     <tr>
       <td>Type inference for object declarations</td>
       <td><a href="https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3007.htm">N3007</a></td>
-      <td class="none" align="center">No</td>
+      <td class="unreleased" align="center">Clang 16</td>
     </tr>
     <tr>
       <td>constexpr for object definitions</td>
       <td><a href="https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3018.htm">N3018</a></td>
       <td class="none" align="center">No</td>
     </tr>
     <tr>
       <td>Introduce storage class specifiers for compound literals</td>
       <td><a href="https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3038.htm">N3038</a></td>
       <td class="none" align="center">No</td>
     </tr>
     <tr>
       <td>Identifier primary expressions</td>
       <td><a href="https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3034.pdf">N3034</a></td>
       <td class="full" align="center">Yes</td>
     </tr>
     <tr>