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? Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D111400/new/ https://reviews.llvm.org/D111400 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
