[PATCH] D111400: [Clang] Implement P2242R3

Aaron Ballman via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Thu Jan 20 11:11:38 PST 2022

aaron.ballman added a comment.

In D111400#3246323 <https://reviews.llvm.org/D111400#3246323>, @cor3ntin wrote:

> In D111400#3243826 <https://reviews.llvm.org/D111400#3243826>, @aaron.ballman wrote:
>> In D111400#3172097 <https://reviews.llvm.org/D111400#3172097>, @cor3ntin wrote:
>>> Regression compared to the status quo:
>>> This code no longer warns (as noted by Hubert above)
>>>   auto f = [](bool b) {
>>>     if (b) return 42;
>>>     static int x = 0;
>>>     return x;
>>>   };
>>>   constexpr int x = f(true);
>>>   const int *p = &x;
>>> GCC doesn't warn and... if we wanted to produce a warning there, I have no idea how to go about it.
>> I think I found the issue in the code, but one thing that's strange is that we don't seem to treat it as an extension but instead issue an error, but the behavior is consistent with other things we handle as an extension there (e.g., a local variable in C++14 mode).
> Yes, that was a bug, but the code above cannot be diagnose.
> at the time when the lambda f() is parsed, there is no indication that it must be usable in a constexpr context, and so the compiler doesn't emit a diagnostic.
> It does when the call operator is marked explicitly `constexpr`
>   auto f = [] (bool b) constexpr {
>     if (b) return 42;
>     static int x = 0;
>     return x;
>   };
>   constexpr int x = f(true);
>   const int *p = &x;
> This behavior is identical to GCC's https://compiler-explorer.com/z/xor3oYGMa

Agreed -- if the lambda function doesn't satisfy the requirements for a constexpr function, then its function call operator is not marked as constexpr, but that only gets diagnosed once the function is used in a constexpr context.

@hubert.reinterpretcast -- how does this patch look to you now?

  rG LLVM Github Monorepo



More information about the cfe-commits mailing list