[llvm-bugs] [Bug 40896] New: clang incorrectly generates noexcept assignment operator

via llvm-bugs llvm-bugs at lists.llvm.org
Wed Feb 27 20:34:35 PST 2019


https://bugs.llvm.org/show_bug.cgi?id=40896

            Bug ID: 40896
           Summary: clang incorrectly generates noexcept assignment
                    operator
           Product: clang
           Version: 7.0
          Hardware: All
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++11
          Assignee: unassignedclangbugs at nondot.org
          Reporter: alexey.kutumov at gmail.com
                CC: blitzrakete at gmail.com, dgregor at apple.com,
                    erik.pilkington at gmail.com, llvm-bugs at lists.llvm.org,
                    richard-llvm at metafoo.co.uk

Created attachment 21525
  --> https://bugs.llvm.org/attachment.cgi?id=21525&action=edit
Program 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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20190228/0e62a877/attachment-0001.html>


More information about the llvm-bugs mailing list