[clang] Define the `__cpp_consteval` macro now that support is complete

[BertalanD]

Commit 3d2629d marked consteval support as completed for the Clang 15 release in the docs. However, the __cpp_consteval feature test macro is still not defined. If the feature is indeed production-ready, it would be nice to define this macro, both on main and the release branch.

llvm-project/clang/lib/Frontend/InitPreprocessor.cpp

Line 679 in 0b12f77

//Builder.defineMacro("__cpp_consteval", "201811L");

cc @cor3ntin, @ChuanqiXu9

See also #53906

[llvmbot]

@llvm/issue-subscribers-clang-frontend

[cor3ntin]

There are still some bugs in the implementation so i think it made sense to be conservative in 15 but we should strive to add the macro in clang 16.

@AaronBallman

[llvmbot]

@llvm/issue-subscribers-c-20

[AaronBallman]

There are still some bugs in the implementation so i think it made sense to be conservative in 15 but we should strive to add the macro in clang 16.

@AaronBallman

I agree -- we're close to being complete, but I think there's still some outstanding bugs we should address before we provide the macro. That said, we might discover new bugs by enabling the macro and trying out some large projects (in case anyone is looking for an experiment to run and report back on).

[AaronBallman]

I did some investigating and we're not as close as I'd like to be. Specifically, there are a few outstanding cases from P1073R3 that we don't handle properly:

namespace P1073R3 {
consteval int f() { return 42; } // expected-note 3 {{declared here}}
consteval auto g() { return f; }
// FIXME: there should be no diagnostics associated with either h() or r.
consteval int h(int (*p)() = g()) { return p(); } // expected-error {{call to consteval function 'P1073R3::g' is not a constant expression}} \
                                                     expected-note {{declared here}} \
                                                     expected-note {{pointer to a consteval declaration is not a constant expression}}
constexpr int r = h();   // expected-note {{in the default initalizer of 'p'}}
constexpr auto e = g();  // expected-error {{call to consteval function 'P1073R3::g' is not a constant expression}} \
                            expected-error {{constexpr variable 'e' must be initialized by a constant expression}} \
                            expected-note 2 {{pointer to a consteval declaration is not a constant expression}}
} // namespace P1073R3

namespace P1073R3 {
struct N {
  constexpr N() {}
  N(N const&) = delete;
};

template<typename T> constexpr void bad_assert_copyable() { T t; T t2 = t; }
using ineffective = decltype(bad_assert_copyable<N>());

// bad_assert_copyable<N> is not needed for constant evaluation
// (and thus not instantiated)
template<typename T> consteval void assert_copyable() { T t; T t2 = t; }
using check = decltype(assert_copyable<N>());
// FIXME: this should give an error because assert_copyable<N> is instantiated
// (because it is needed for constant evaluation), but the attempt to copy t is
// ill-formed.
} // namespace P1073R3

There is some implementation divergence, but I believe Clang's behavior is the least conforming of the implementations tested: https://godbolt.org/z/soMs4aWGo

[AaronBallman]

FWIW, I posted https://reviews.llvm.org/D144572 to try to update the public status page and get more info into the test suite as to what functionality is still missing before we should claim full support (IMO).

[Fznamznon]

Specifically, there are a few outstanding cases from P1073R3 that we don't handle properly

I'm looking into these.

[Fznamznon]

Here is an attempt to fix the first one - https://reviews.llvm.org/D145251 .