[PATCH] D147909: [clang] Implement CWG 2397

Younan Zhang via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Tue Apr 11 22:25:29 PDT 2023


zyounan added a comment.

Thank you for the suggestion and I've updated my patch. :)



================
Comment at: clang/test/CXX/dcl.decl/dcl.meaning/dcl.array/cwg2397.cpp:11
+}
+
+void g() {
----------------
aaron.ballman wrote:
> I think it'd be good to also show a constexpr test, like:
> ```
> constexpr int foo() {
>   int a[] = { 1, 2, 3 };
>   auto (&c)[3] = a;
> 
>   return c[2];
> }
> 
> static_assert(foo() == 3, "");
> ```
> to prove that we actually perform the assignment properly, not just figure out the deduced type correctly.
Indeed. I will enable it only with C++14 or later. (I didn't come up a way to get around the restriction for C++11, though.)


================
Comment at: clang/test/CXX/dcl.decl/dcl.meaning/dcl.array/p1-cxx0x.cpp:5
   int b[5];
-  auto a[5] = b; // expected-error{{'a' declared as array of 'auto'}}
-  auto *c[5] = b; // expected-error{{'c' declared as array of 'auto *'}}
+  auto a[5] = b; // expected-error{{variable 'a' with type 'auto[5]' has incompatible initializer of type 'int[5]'}}
+  auto *c[5] = b; // expected-error{{variable 'c' with type 'auto *[5]' has incompatible initializer of type 'int[5]'}}
----------------
aaron.ballman wrote:
> I've seen worse diagnostics, but the phrasing here is interesting -- if you use `int a[5] = b;` instead of `auto`, you get `array initializer must be an initializer list` as a diagnostic, so I wonder why we're getting such a drastically different diagnostic for `auto`. Same for the diagnostic below.
You're right that such diagnostic looks a bit strange but FYI, GCC now emits diagnostic like so:
```
auto a[5] = b; // error: unable to deduce 'auto [5]' from 'b'
int c[5] = b;  // error: array must be initialized with a brace-enclosed initializer
```
I agree that what we expect here is to emit messages just like `int a[5] = b;` would produce with respect to better understandability, however, the `err_auto_var_deduction_failure` error is actually emitted due to type deduction failure, whereas `err_array_init_not_init_list` would be produced **later** by initialization error IIUC. So, IMHO such message makes sence as per what standard says, that for each type `P`, after being substituted with deduced `A`, shall be **compatible** with type `A`. [temp.deduct.type/1](https://eel.is/c++draft/temp.deduct.type#1.sentence-1)

// Feel free to correct me if I'm wrong :)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D147909



More information about the cfe-commits mailing list