[llvm-bugs] [Bug 41900] New: std::allocate_shared can't allocate object with private constructor

[via llvm-bugs]

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

            Bug ID: 41900
           Summary: std::allocate_shared can't allocate object with
                    private constructor
           Product: libc++
           Version: 8.0
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: All Bugs
          Assignee: unassignedclangbugs at nondot.org
          Reporter: laurent.pinchart at ideasonboard.com
                CC: llvm-bugs at lists.llvm.org, mclow.lists at gmail.com

I ran into what I believe can be a bug in the libc++ implementation of
std::allocate_shared<>. The following code fails to compile due to two
issues.

------------------------------------------------------------------------
#include <memory>

class Private;

class Factory {
public:
        static std::shared_ptr<Private> allocate();
};

class Private {
private:
        friend class Factory;
        Private() { }
        ~Private() { }
};

std::shared_ptr<Private> Factory::allocate()
{
        struct Allocator : std::allocator<Private> {
                void construct(void *p)
                {
                        ::new(p) Private();
                }
                void destroy(Private *p)
                {
                        p->~Private();
                }
        };

        return std::allocate_shared<Private>(Allocator());
}
------------------------------------------------------------------------

First of all, commit 7700912976a5 ("Land D28253 which fixes PR28929
(which we mistakenly marked as fixed before)") introduced a static
assert to verify that the object type is constructible:

static_assert( is_constructible<_Tp, _Args...>::value, "Can't construct object
in allocate_shared" );

This fails, as Private is not constructible in the context of the
std::allocate_shared<> implementations, due to its private constructor
and destructor. I believe that the check is incorrect, as I don't see
anything in the C++ standard that mandates the object type to be
constructible by std::allocate_shared<> itself.

I tried removing the static asserts, and that's where the real fun
began. If my understanding is correct, in order to store the pointed
data, libc++ uses an internal __shared_ptr_emplace<_Tp, _Alloc> class
that contains (through a few levels of inheritance) an instance of _Tp.
That class has its destructor implicitly deleted due to the private
nature of ~Private(). The compiler then complains about

/usr/include/c++/v1/memory:3604:7: error: deleted function
'~__shared_ptr_emplace' cannot override a non-deleted function
class __shared_ptr_emplace
[...]
/usr/include/c++/v1/memory:3513:13: note: overridden virtual function is here
    virtual ~__shared_weak_count();

-- 
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/20190516/8cf0fc79/attachment-0001.html>