[Bug c++/89533] New: G++ incorrectly generates noexcept assignment operator

[alexey.kutumov at gmail dot com]

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

            Bug ID: 89533
           Summary: G++ incorrectly generates noexcept assignment operator
           Product: gcc
           Version: 8.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: alexey.kutumov at gmail dot com
  Target Milestone: ---

Created attachment 45852
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45852&action=edit
minimal sample which reproduces problem

Consider following example (bad.cpp in atttachment). In this example i have
struct VectorWrapper with following assignment operator:

VectorWrapper& operator=(VectorWrapper) noexcept {
    return *this;
}
Which is really noexcept


And copy ctor:
VectorWrapper(const VectorWrapper& ){
    throw 42;
}
Which is *not* noexcept


If i wrap this struct into
struct MyData {
    VectorWrapper vec;
};


And tries to copy one instance of MyData into another my program crashes even
if i try to catch exception (as seen in bad.cpp).


I suppose that compiler marks assignment operator of MyData as *noexcept* while
it actually is *NOT* noexcept, because it calls copy ctor of VectorWrapper.


I've filed same bug to MSVC:
https://developercommunity.visualstudio.com/content/problem/456988/program-crashes-while-throwing-exception-inside-ge.html?childToView=470086#comment-470086

They said that there is a bug in implementation:

For reference, here's what the Standard has to say:

The exception specification for an implicitly-declared assignment operator, or
an assignment-operator without a noexcept-specifier that is defaulted on its
first declaration, is potentially-throwing if and only if the invocation of any
assignment operator in the implicit definition is potentially-throwing

http://eel.is/c++draft/except.spec#9

Our interpretation of "invocation of any assignment operator" includes the
argument conversions required, not just the specific function(s) being called.
This wording changed quite a bit since C++14, where it explicitly called out
"any function it directly invokes" which would more obviously include the copy
constructor call, yet still no compiler I tried implemented this.