[PATCH] D155064: [clang][SemaCXX] Diagnose tautological uses of consteval if and is_constant_evaluated

Takuya Shimizu via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Sun Jul 23 04:26:16 PDT 2023


hazohelet added inline comments.


================
Comment at: clang/test/SemaCXX/vartemplate-lambda.cpp:17
+                                                        // expected-note{{cannot be used in a constant expression}} \
+                                                        // expected-error 2{{a lambda expression may not appear inside of a constant expression}}
 };
----------------
cor3ntin wrote:
> This also looks like a regression.
> 
> The current error is much clearer, can you investigate?
> ```
> <source>:3:22: error: constexpr variable 't<int>' must be initialized by a constant expression
>     3 |   static constexpr T t = [](int f = T(7)){return f;}();
>       |                      ^   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> <source>:6:12: note: in instantiation of static data member 'S::t<int>' requested here
>     6 | int a = S::t<int>;
>       |            ^
> <source>:3:26: note: non-literal type 'S::(lambda at <source>:3:26)' cannot be used in a constant expression
>     3 |   static constexpr T t = [](int f = T(7)){return f;}();
>       |                          ^
> ```
> 
> Why do we emt 2 errors instead of a single note? Here the error is that the initializer is not a constant expression, everything else should be notes.
"lambda cannot be in constant expression" error is emitted from Sema against lambda expressions in constant-evaluated contexts in C++14 mode, and the note is emitted from constexpr evaluator.
The Sema-side error is emitted twice because it is emitted both before/after instantiation.
We can suppress one of them by ignoring it when sema is instantiating variable template initializer.
Or we can completely suppress this Sema error against initializers to avoid duplicate errors from Sema and constexpr evaluator.
I think "lambda cannot be in constant expression" Sema error is more understandable than the constexpr evaluator note "non-literal type cannot be in constant expression", so I think it is ok to keep one Sema error here.


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

https://reviews.llvm.org/D155064



More information about the cfe-commits mailing list