[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


            Bug ID: 40896
           Summary: clang incorrectly generates noexcept assignment
           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:

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


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