[C++20] Claim full support for consteval again

[Fznamznon]

Summary

After resolving several outstanding issues now is the time to mark it as
fully supported.

Fixes https://github.com/llvm/llvm-project/issues/57094

[cor3ntin]

LGTM.
Thanks for completing this :)

[erichkeane]

@cjdb has been running some GDB test suites against our compiler: I am wondering if we could ask him to try the consteval ones too before we set this?

[shafik]

In D147717#4248989, @erichkeane wrote:

@cjdb has been running some GDB test suites against our compiler: I am wondering if we could ask him to try the consteval ones too before we set this?

This is probably a good idea.

[cjdb]

In D147717#4248989, @erichkeane wrote:

@cjdb has been running some GDB test suites against our compiler: I am wondering if we could ask him to try the consteval ones too before we set this?

A lot of that work is manual because I need to interpret LIT messages to know wether something is a config error (e.g. missing // expected-no-diagnostics), a difference in opinion between compilers (e.g. GCC says it's an error and Clang says it's a note, reporting diagnostics on different lines, etc.), or actually an error in Clang.

I won't have time to check this week, but perhaps next week if the test set isn't too large (failing that, I'll at least try to get you // expected-no-diagnostics for improved confidence). Does this timeframe seem acceptable?

[aaron.ballman]

In D147717#4249929, @cjdb wrote:

In D147717#4248989, @erichkeane wrote:

@cjdb has been running some GDB test suites against our compiler: I am wondering if we could ask him to try the consteval ones too before we set this?

A lot of that work is manual because I need to interpret LIT messages to know wether something is a config error (e.g. missing // expected-no-diagnostics), a difference in opinion between compilers (e.g. GCC says it's an error and Clang says it's a note, reporting diagnostics on different lines, etc.), or actually an error in Clang.

I won't have time to check this week, but perhaps next week if the test set isn't too large (failing that, I'll at least try to get you // expected-no-diagnostics for improved confidence). Does this timeframe seem acceptable?

That sounds perfect to me -- there's not a rush on defining the macro/updating the status page given that we're not near a release, so we can wait until we have more details. Thank you for the help, @cjdb!

[cjdb]

I'm gonna get started on this today!

[Fznamznon]

In D147717#4275410, @cjdb wrote:

I'm gonna get started on this today!

@cjdb , how is this going? I've seen https://github.com/llvm/llvm-project/issues/62224, but no more issues with consteval label.

[cjdb]

In D147717#4312066, @Fznamznon wrote:

In D147717#4275410, @cjdb wrote:

I'm gonna get started on this today!

@cjdb , how is this going? I've seen https://github.com/llvm/llvm-project/issues/62224, but no more issues with consteval label.

I haven't had time to invest in this recently, as I've been gearing up for an intern.

[Fznamznon]

Friendly ping. It is been a while.
@cjdb , any chance for an update?

[cor3ntin]

I think we should make sure to land this for clang 17. The rate of consteval bugs is no greater than that of any other feature at this point.

[Fznamznon]

In D147717#4393019, @cor3ntin wrote:

I think we should make sure to land this for clang 17. The rate of consteval bugs is no greater than that of any other feature at this point.

There is https://github.com/llvm/llvm-project/issues/62886 which seems quite ugly, but has a patch on review.
Otherwise I agree, I'm not seeing more consteval bugs than any others.
@aaron.ballman , @erichkeane wdyt about landing it?

[cjdb]

In D147717#4395204, @Fznamznon wrote:

In D147717#4393019, @cor3ntin wrote:

I think we should make sure to land this for clang 17. The rate of consteval bugs is no greater than that of any other feature at this point.

There is https://github.com/llvm/llvm-project/issues/62886 which seems quite ugly, but has a patch on review.
Otherwise I agree, I'm not seeing more consteval bugs than any others.
@aaron.ballman , @erichkeane wdyt about landing it?

The worst-case scenario is that we have to disable the status again. I can't give an estimate on when I'll finish, so this is fine to me based on available data.

[aaron.ballman]

In D147717#4396432, @cjdb wrote:

In D147717#4395204, @Fznamznon wrote:

In D147717#4393019, @cor3ntin wrote:

I think we should make sure to land this for clang 17. The rate of consteval bugs is no greater than that of any other feature at this point.

There is https://github.com/llvm/llvm-project/issues/62886 which seems quite ugly, but has a patch on review.
Otherwise I agree, I'm not seeing more consteval bugs than any others.
@aaron.ballman , @erichkeane wdyt about landing it?

The worst-case scenario is that we have to disable the status again. I can't give an estimate on when I'll finish, so this is fine to me based on available data.

I'd rather not claim support and then pull that back later (that increases confusion for users). That said, looking at the issues we have open for consteval in the issue tracker doesn't show any major issues that don't already have folks working on a fix for them. #62886 is the one that bothers me the most, but @Fznamznon already has a patch going for it that's progressing well. So I'm okay with landing this and claiming full support, but let's do that once the consteval operator bug is closed. WDYT?

[cor3ntin]

Works for me

[philnik]

https://github.com/llvm/llvm-project/issues/60709 seems also pretty scary to me.

[Fznamznon]

Rebase, update value of macro since P2564 is implemented now

[Fznamznon]

https://github.com/llvm/llvm-project/issues/62886 has been fixed, I'm trying to figure out or at least reduce https://github.com/llvm/llvm-project/issues/60709 so it doesn't have headers included, but no progress so far.

[aaron.ballman]

LGTM (though I wonder if we should add a release note as well)

[Fznamznon]

In D147717#4413522, @aaron.ballman wrote:

LGTM (though I wonder if we should add a release note as well)

I can add a note saying that the macro is now defined. Is somewhere under C++ Language Changes title the right place to do that?

[aaron.ballman]

In D147717#4413593, @Fznamznon wrote:

In D147717#4413522, @aaron.ballman wrote:

LGTM (though I wonder if we should add a release note as well)

I can add a note saying that the macro is now defined. Is somewhere under C++ Language Changes title the right place to do that?

Yeah, probably in the C++20 section specifically.

[Fznamznon]

Rebase, add a release note

[Fznamznon]

The CI failure is unrelated and I suppose should be already fixed by aa28875.

clang/docs/ReleaseNotes.rst

- Downgraded use of a reserved identifier in a module export declaration from
   building of standard modules. This diagnostic may be strengthened into an
   error again in the future once there is a less fragile way to mark a module
   as being part of the implementation rather than a user module.
 - Clang now implements `[temp.deduct]p9`. Substitution failures inside lambdas from
   unevaluated contexts will be surfaced as errors. They were previously handled as
   SFINAE.
 - Clang now supports `requires cplusplus20` for module maps.
 - Implemented missing parts of `P2002R1: Consistent comparison operators <https://wg21.link/P2002R1>`_
+- Clang now defines `__cpp_consteval` macro.
 
 C++23 Feature Support
 ^^^^^^^^^^^^^^^^^^^^^
 
 - Implemented `P2036R3: Change scope of lambda trailing-return-type <https://wg21.link/P2036R3>`_
   and `P2579R0 Mitigation strategies for P2036 <https://wg21.link/P2579R0>`_.
   These proposals modify how variables captured in lambdas can appear in trailing return type
   expressions and how their types are deduced therein, in all C++ language versions.

clang/lib/Frontend/InitPreprocessor.cpp

static void InitializeCPlusPlusFeatureTestMacros(const LangOptions &LangOpts,
   if (LangOpts.CPlusPlus20) {
     Builder.defineMacro("__cpp_aggregate_paren_init", "201902L");
 
     // P0848 is implemented, but we're still waiting for other concepts
     // issues to be addressed before bumping __cpp_concepts up to 202002L.
     // Refer to the discussion of this at https://reviews.llvm.org/D128619.
     Builder.defineMacro("__cpp_concepts", "201907L");
     Builder.defineMacro("__cpp_conditional_explicit", "201806L");
-    // Builder.defineMacro("__cpp_consteval", "202211L");
+    Builder.defineMacro("__cpp_consteval", "202211L");
     Builder.defineMacro("__cpp_constexpr_dynamic_alloc", "201907L");
     Builder.defineMacro("__cpp_constinit", "201907L");
     Builder.defineMacro("__cpp_impl_coroutine", "201902L");
     Builder.defineMacro("__cpp_designated_initializers", "201707L");
     Builder.defineMacro("__cpp_impl_three_way_comparison", "201907L");
     //Builder.defineMacro("__cpp_modules", "201907L");
     Builder.defineMacro("__cpp_using_enum", "201907L");
   }

clang/test/Lexer/cxx-features.cpp

 #if check(concepts, 0, 0, 0, 0, 201907, 201907)
 #error "wrong value for __cpp_concepts"
 #endif
 
 #if check(conditional_explicit, 0, 0, 0, 0, 201806, 201806)
 #error "wrong value for __cpp_conditional_explicit"
 #endif
 
-#if check(consteval, 0, 0, 0, 0, 0, 0)
-// FIXME: 201811 in C++20
+#if check(consteval, 0, 0, 0, 0, 202211, 202211)
 #error "wrong value for __cpp_consteval"
 #endif
 
 // constexpr checked below
 
 #if check(constexpr_dynamic_alloc, 0, 0, 0, 0, 201907, 201907)
 #error "wrong value for __cpp_constexpr_dynamic_alloc"
 #endif

clang/www/cxx_status.html

</tr>
     <tr>
       <td><tt>char8_t</tt></td>
       <td><a href="https://wg21.link/p0482r6">P0482R6</a></td>
       <td class="full" align="center">Clang 7 <a href="#p0482">(11)</a></td>
     </tr>
     <tr>
       <td rowspan=2>Immediate functions (<tt>consteval</tt>)</td>
       <td><a href="https://wg21.link/p1073r3">P1073R3</a></td>
-      <td class="partial" align="center">
-        <details><summary>Clang 15 (Partial)</summary>
-          Clang still incorrectly defers some consteval executions to runtime,
-          resulting in CodeGen crashes. Additionally, Clang does not properly
-          handle default arguments in consteval functions under all
-          circumstances.
-        </details>
-      </td>
+      <td class="full" align="center">Clang 17</td>
     </tr>
       <tr> <!-- from Prague -->
         <td><a href="https://wg21.link/p1937r2">P1937R2</a></td>
         <td class="full" align="center">Clang 14</td>
       </tr>
     <tr>
       <td><tt>std::is_constant_evaluated</tt></td>
       <td><a href="https://wg21.link/p0595r2">P0595R2</a></td>