[Bug c++/104850] New: Instantiating a destructor for a template class too early, before the calling destructor is seen - rejects valid code

[Bug c++/104850] New: Instantiating a destructor for a template class too early, before the calling destructor is seen - rejects valid code

[kirshamir at gmail dot com]

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

            Bug ID: 104850
           Summary: Instantiating a destructor for a template class too
                    early, before the calling destructor is seen - rejects
                    valid code
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: kirshamir at gmail dot com
  Target Milestone: ---

The following code is rejected as trying to use incomplete type, while when the
actual use would actually appear the type would be complete:

template<typename T>
struct uptr {
    uptr(nullptr_t) {}
    ~uptr() {
        delete (new T);
    }
};

class A
{
public:
  A();
  ~A();
private:
  class B;
  uptr<B> m_b = nullptr; // the dtor of uptr tries to be instantiated here
};

If we change the initialization of:
uptr<B> m_b = nullptr; 
To:
uptr<B> m_b {nullptr}; 

The destructor instantiation is delayed, till ~A() is seen, and the code can be
compiled.

See:
https://stackoverflow.com/questions/71397495/why-does-default-member-initializer-request-instantiation-of-unique-ptr-destru

[Bug c++/104850] Instantiating a destructor for a template class too early, before the calling destructor is seen - rejects valid code

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2022-03-09
           Keywords|                            |rejects-valid
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |WAITING

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
I get

t.ii:3:10: error: unknown type name 'nullptr_t'
    uptr(nullptr_t) {}
         ^

please fix your example.

[Bug c++/104850] Instantiating a destructor for a template class too early, before the calling destructor is seen - rejects valid code

[kirshamir at gmail dot com]

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

--- Comment #2 from Amir Kirsh <kirshamir at gmail dot com> ---
// adding the required include to the example

#include <cstddef> // for nullptr_t

template<typename T>
struct uptr {
    uptr(nullptr_t) {}
    ~uptr() {
        delete (new T);
    }
};

class A
{
public:
  A();
  ~A();
private:
  class B;
  uptr<B> m_b = nullptr; // the dtor of uptr tries to be instantiated here
};

https://wandbox.org/permlink/rJeeB3Sliey6tGzR

If we change the initialization of:
uptr<B> m_b = nullptr; 
To:
uptr<B> m_b {nullptr}; 

Relevant SO post:
https://stackoverflow.com/questions/71397495/why-does-default-member-initializer-request-instantiation-of-unique-ptr-destru/71402270#71402270

[Bug c++/104850] Instantiating a destructor for a template class too early, before the calling destructor is seen - rejects valid code

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
clang and ICC also reject this for the same reason as GCC.
MSVC on the other hand accepts this.

[Bug c++/104850] Instantiating a destructor for a template class too early, before the calling destructor is seen - rejects valid code

[pinskia at gcc dot gnu.org]

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

--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Interesting if I put the definition of the class A::B at the end of the file,
the code works ....

I wonder if this is because of some ABI issue where A::A as a base class is
created ....

[Bug c++/104850] Instantiating a destructor for a template class too early, before the calling destructor is seen - rejects valid code

[de34 at live dot cn]

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

Jiang An <de34 at live dot cn> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |de34 at live dot cn

--- Comment #5 from Jiang An <de34 at live dot cn> ---
Clang started to accept this since Clang 16. https://godbolt.org/z/c6vGzTP48

[Bug c++/104850] Instantiating a destructor for a template class too early, before the calling destructor is seen - rejects valid code

[benni.buch at gmail dot com]

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

Benjamin Buch <benni.buch at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |benni.buch at gmail dot com

--- Comment #6 from Benjamin Buch <benni.buch at gmail dot com> ---
I think this is a sub-case of Bug 104850

[Bug c++/104850] Instantiating a destructor for a template class too early, before the calling destructor is seen - rejects valid code

[benni.buch at gmail dot com]

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

--- Comment #7 from Benjamin Buch <benni.buch at gmail dot com> ---
Sorry wrong number; Bug 114076

[Bug c++/104850] Instantiating a destructor for a template class too early, before the calling destructor is seen - rejects valid code

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://gcc.gnu.org/bugzill
                   |                            |a/show_bug.cgi?id=96645

--- Comment #8 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Seems related to PR 96645 (and CWG2335).