[LLVMbugs] [Bug 13381] New: const member data not taken into account for implicitly generated move constructor

bugzilla-daemon at llvm.org bugzilla-daemon at llvm.org
Tue Jul 17 07:42:20 PDT 2012


http://llvm.org/bugs/show_bug.cgi?id=13381

             Bug #: 13381
           Summary: const member data not taken into account for
                    implicitly generated move constructor
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: C++11
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: hhinnant at apple.com
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Consider:


struct string
{
    string() noexcept;
    string(const string&);
    string& operator=(const string&);
    string(string&&) noexcept;
    string& operator=(string&&) noexcept;
};

struct unique_ptr
{
    unique_ptr() noexcept;
    unique_ptr(unique_ptr&&) noexcept;
    unique_ptr& operator=(unique_ptr&&) noexcept;
};

struct wrap
{
   const string data;
   unique_ptr data2;
};

wrap make() noexcept;

int main()
{
    static_assert(noexcept(wrap(make())), "");
}

This compiles.  I expect it not to because the move construction of wrap ought
not to be noexcept.  But it appears that the analysis is using the string move
constructor in its analysis.  But a const string can't be moved from.  For
example I expect that the implicit move constructor would look like:

  wrap(wrap&& w)
     : data(static_cast<const string&&>(w.data)),  // calls string copy ctor
       data2(static_cast<unique_ptr&&>(w.data2))   // calls unique_ptr move
ctor
     {}

The first construction is noexcept(false), the second is noexcept(true), so I
expect the wrap move constructor to be noexcept(false).

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.



More information about the llvm-bugs mailing list