noexcept specifiers are evaluated incorrectly

[lukasm91]

Bugzilla Link	37559
Version	trunk
OS	Linux
CC	@DougGregor,@zygoloid

Extended Description

There seem to be some problems about the point where noexcept specifiers are evaluated. I.e., this code does not compile:

void some_function() noexcept;

class V1 {
// does not compile
void f() noexcept(noexcept(some_function()));
decltype(&V1::f) f2;
};

class V2 {
// does not compile
void f() noexcept(true);
decltype(&V2::f) f2;
};

class V3 {
// compiles
void f() noexcept;
decltype(&V3::f) f2;
};

due to

:5:17: error: exception specification is not available until end of class definition

decltype(&V1::f) f2;

            ^

:11:17: error: exception specification is not available until end of class definition

decltype(&V2::f) f2;

            ^

2 errors generated.

Compiler returned: 1

[lukasm91]

This bug affects:

-std=c++11, -std=c++14 and -std=c++17

clang 5.0, clang 6.0 and trunk

[zygoloid]

Clang is approximately correct to reject that code.

Per [except.spec]/13.1, the exception specification of V1::f is needed by the decltype(&V1::f).

Per C++ DR1330, exception specifications are not parsed until we reach the end of the class (they can name class members that are declared later, and the class is complete within them), just like member function bodies, default member initializers, and default arguments.

Finally, there's C++ DR361 (still open 16 years after being filed, sadly), wherein the conclusion of CWG is that the program is ill-formed if you use a delay-parsed construct before the end of the class. But we don't have actual standards wording to back that up yet, just a standard that's unimplementable without a fix to that defect.

Here's a simple example of the kind of trouble you run into in this area:

struct V1 {
static void f() noexcept(b);
static constexpr bool b = !noexcept(f());
};

Every other compiler gets this wrong in some way: EDG crashes, GCC incorrectly reports that 'b' is not in scope in the exception-specification of 'f' (because it doesn't implement DR1330), MSVC reports that 'b' is not in scope and then crashes.

However, Clang is arguably wrong to accept your example V3. We treat plain 'noexcept' as being special: we don't need to parse any expression to know what it means, so there's no need to delay handling it. But making Clang reject V3 doesn't seem like a useful change.

[lukasm91]

Thanks for this explanation. This was very useful!

Clang is approximately correct to reject that code.
Thats an amazing wording!

struct V4 { // changed to V4
static void f() noexcept(b); // static void f() noexcept(true);
static constexpr bool b = !noexcept(f());
};

In this example b is not needed in noexcept. Another example which in principle has nothing to do with noexcept-specifiers:

struct V5 {
static int f() noexcept(true); // or even noexcept if strictly following the standard
static decltype(f()) i;
};

I am pretty sure that the noexcept-specifier in principle is not needed to get decltype(f()). In regard of DR 1330 it makes totally sense that this example fails, but I am not sure if this is really what we should aim for ...

But making Clang reject V3 doesn't seem like a useful change.

I agree that it does not look like a useful change in the first place, but on the other hand it would help to estimate the consequences of DR 1330. Especially examples such as V5 or traits based on decltype(&C::f) look quite reasonable to me.

Additionally: I am not sure whether all these codes (except the one you posted) should compile with C++11 / C++14: As noexcept is not part of the signature it may be unnecessary to evaluate that. If that's true, this for sure is a minor issue with very low to no priority because we are in a vaguely defined area of C++ standards.

[zygoloid]

struct V5 {
static int f() noexcept(true); // or even noexcept if strictly following
the standard
static decltype(f()) i;
};

I am pretty sure that the noexcept-specifier in principle is not needed to
get decltype(f()).

Yeah. However, we do have a formal notion of when an exception specification is "needed" ([except.spec]p13) that applies, for instance, to the template case:

template int f() noexcept(true);
decltype(f()) i; // triggers instantiation of exception specification of f

... and it makes some sense for that rule to also be used here.

More generally I think the "right" approach is to treat these delay-parsed regions more like we treat templates -- that is, parse them at the end of the class or at the first point at which they're needed, whichever comes first. Then the only case which we need to diagnose is the case where there's an actual cycle. I've been pushing for this in the C++ committee for a few years but so far implementation concerns have won out.

[llvmbot]

@llvm/issue-subscribers-clang-frontend

[Fedr]

Probably related. This C++17 program

struct A {
    template<class=void> //if this line is removed, Clang accepts the program
    void foo() noexcept(true) {}
    auto bar() -> decltype(foo()) {}
};

is accepted by GCC and MSVC but Clang complains:

error: exception specification is not available until end of class definition
    4 |     auto bar() -> decltype(foo()) {}
      |                            ^

If one makes foo() not a function template, then the program is accepted. Online demo: https://gcc.godbolt.org/z/7x1GbPWT7

Original discussion: https://stackoverflow.com/q/79081096/7325599