[Bug c++/115222] New: clang does not think libstdc++'s std::optional is nothrow destructible

[Bug c++/115222] New: clang does not think libstdc++'s std::optional is nothrow destructible

[pobrn at protonmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115222

            Bug ID: 115222
           Summary: clang does not think libstdc++'s std::optional is
                    nothrow destructible
           Product: gcc
           Version: 15.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: pobrn at protonmail dot com
  Target Milestone: ---

clang and gcc disagree whether libstdc++'s std::optional<T> is nothrow
destructible when T is not. My reading of https://eel.is/c++draft/optional.dtor
suggests that the destructor should be `noexcept(true)` (by omission).

Consider the following piece of C++ code:

```
#include <optional>
#include <type_traits>

struct A { ~A() noexcept(false); };

static_assert(std::is_nothrow_destructible_v<std::optional<A>>);
```

the assertion passes on gcc, while it fails on clang:
https://gcc.godbolt.org/z/1ndxK1avM

Now I have tried to reduce the input, and arrived at something like this (
https://gcc.godbolt.org/z/orx5j1Eaf ):

```
template <typename _Tp> _Tp declval() noexcept;

template <typename _Tp>
inline constexpr bool is_nothrow_destructible_v = noexcept(declval<_Tp>());

template <typename _Tp>
struct _Optional_payload_base {
  union _Storage {
    _Tp _M_value;
  } _M_payload;
};

template <typename _Tp>
struct _Optional_payload : _Optional_payload_base<_Tp> {
    ~_Optional_payload();
};

struct A {
  ~A() noexcept(false);
};

static_assert(is_nothrow_destructible_v<_Optional_payload<A>>);
```

The assertion passes on gcc, but fails on clang (and edg).

[Bug c++/115222] clang does not think libstdc++'s std::optional is nothrow destructible

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115222

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
here is a much reduced testcase:
```
struct A {
  ~A() noexcept(false);
};
union _Storage {
    A _M_value;
    ~_Storage();
};
static_assert(noexcept(_Storage{}));
```

[Bug c++/115222] gcc ignores noexcept on fields' deconstructors in an union

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115222

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2024-05-25
     Ever confirmed|0                           |1

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
https://eel.is/c++draft/except.spec#8 is the part of the spec that matters
here.

Specifically: "is potentially-throwing if and only if any of the destructors
for any of its potentially constructed subobjects"

Confirmed.

[Bug c++/115222] gcc ignores noexcept on fields' deconstructors in an union

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115222

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
C++14 (and C++11) had slightly different wording here:

```
Given a member function f of some class X, where f is an inheriting constructor
(12.9) or an implicitlydeclared special member function, the set of potential
exceptions of the implicitly-declared member function f consists of all the
members from the following sets:

if f is a destructor, the sets of potential exceptions of the destructor
invocations for X’s non-variant non-static data members and for X’s virtual and
direct base classes.

```

Looks like GCC just missed the rule applies to unions too.

[Bug c++/115222] gcc ignores noexcept on fields' deconstructors in an union

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115222

--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Hmm, my reduced testcase has slightly different behavior compared to the
original one for some versions of GCC. The original testcase is partly related
to PR 114844 while my reduced testcase is just missing handling of union.

[Bug c++/115222] gcc ignores noexcept on fields' deconstructors in an union

[harald at gigawatt dot nl]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115222

Harald van Dijk <harald at gigawatt dot nl> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |harald at gigawatt dot nl

--- Comment #5 from Harald van Dijk <harald at gigawatt dot nl> ---
I end up with a different reduced test case that does not involve unions:

template <typename _Tp> _Tp declval() noexcept;

template <typename _Tp>
inline constexpr bool is_nothrow_destructible_v = noexcept(declval<_Tp>());

struct A { ~A() noexcept(false) = delete; };
struct B : A { ~B(); };
static_assert(is_nothrow_destructible_v<B>);

The assertion passes in GCC, fails in clang, but I think clang is right here.
It looks like GCC ignores the deleted destructor for determining whether B's
destructor should be implicitly noexcept, but the wording that Andrew Pinski
referenced in comment #2 says B's destructor is potentially throwing "if any of
the destructors for any of its potentially constructed subobjects has a
potentially-throwing exception specification" without regard to whether those
destructors are deleted.

[Bug c++/115222] gcc ignores noexcept on fields' deconstructors in an union

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115222

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |janschultke at googlemail dot com

--- Comment #6 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
*** Bug 115417 has been marked as a duplicate of this bug. ***