[PATCH] D133289: [C2X] N3007 Type inference for object definitions

Guillot Tony via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Thu Jul 13 12:55:34 PDT 2023


to268 marked an inline comment as done.
to268 added a comment.

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 <https://reviews.llvm.org/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 <https://reviews.llvm.org/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 <https://reviews.llvm.org/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!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D133289



More information about the cfe-commits mailing list