[Bug libstdc++/102199] New: is_default_constructible incorrect for an inner type with NSDMI

[Bug libstdc++/102199] New: is_default_constructible incorrect for an inner type with NSDMI

[eyalroz1 at gmx dot com]

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

            Bug ID: 102199
           Summary: is_default_constructible incorrect for an inner type
                    with NSDMI
           Product: gcc
           Version: 12.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: eyalroz1 at gmx dot com
  Target Milestone: ---

Stackoverflow discussion: https://stackoverflow.com/q/69050558/1593077
Related LLVM bug: https://bugs.llvm.org/show_bug.cgi?id=38374
GodBolt: https://godbolt.org/z/snPf7Ks4W

Consider the following program:

#include <type_traits>

struct outer {
    struct inner {
        // inner() { }
        unsigned int x = 0;
    };
//    static_assert(std::is_default_constructible<inner>::value,
//          "not default ctorable - inside");
};

static_assert(std::is_default_constructible<outer::inner>::value,
    "not default ctorable - outside");

It compiles. But if we uncomment the first static_assert - it evaluates to
false. Mind you: Not because struct inner is incomplete; it is simply deemed to
not be default-constructible. But - it _is_ default constructible. And if we
add a method to struct outer which default-constructs an inner, it will work.

Also note that if we uncomment the explicit default ctor the definition of
struct inner, both asserts pass.


clang++ seems to exhibit this too (also with -stdlib=libc++). I'm not sure
whether this is an actual bug in the library, or whether the standard mandates
this in some freakish way, but - it's just wrong.

[Bug c++/102199] is_default_constructible incorrect for an inner type with NSDMI

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|libstdc++                   |c++

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
THis comes down to when the struct is complete.

[Bug c++/102199] is_default_constructible incorrect for an inner type with NSDMI

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
This is because the following is still valid C++11:
struct outer {
    struct inner {
        // inner() { }
        unsigned int x = y;
    };
  static constexpr int y =10;
};

That is inner is not completed until outer is completed.

[Bug c++/102199] is_default_constructible incorrect for an inner type with NSDMI

[eyalroz1 at gmx dot com]

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

--- Comment #3 from Eyal Rozenberg <eyalroz1 at gmx dot com> ---
Andrew: What you're saying would be plausible if g++ would find the structure
to be incomplete. It does not. The completeness check passes; and it is  why
adding the explicit default ctor makes the asserting pass - despite your
rationale applying to that case just as well.

[Bug c++/102199] is_default_constructible incorrect for an inner type with NSDMI

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely <redi at gcc dot gnu.org> ---
See PR 96645 and PR 101227

[Bug c++/102199] is_default_constructible incorrect for an inner type with NSDMI

[eyalroz1 at gmx dot com]

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

--- Comment #5 from Eyal Rozenberg <eyalroz1 at gmx dot com> ---
(In reply to Jonathan Wakely from comment #4)
> See PR 96645 and PR 101227

Ok, I

[Bug c++/102199] is_default_constructible incorrect for an inner type with NSDMI

[eyalroz1 at gmx dot com]

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

--- Comment #6 from Eyal Rozenberg <eyalroz1 at gmx dot com> ---
(In reply to Jonathan Wakely from comment #4)
> See PR 96645 and PR 101227

Ok.

But does that explain why defining an explicit constructor cause g++ to accept
the class as default-constructible?

[Bug c++/102199] is_default_constructible incorrect for an inner type with NSDMI

[redi at gcc dot gnu.org]

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

--- Comment #7 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Because a user-provided inner() means it's default constructible, period. If
that default constructor happens to be ill-formed, that's your problem and is
outside the immediate context that is checked by is_default_constructible.

Without that user-provided constructor, the compiler has to try to implicitly
define a default constructor, which has to consider all the members and their
default member initializers, which requires the type to be complete.

[Bug c++/102199] is_default_constructible incorrect for an inner type with NSDMI

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mrjoel at lixil dot net

--- Comment #8 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
*** Bug 105606 has been marked as a duplicate of this bug. ***

[Bug c++/102199] is_default_constructible incorrect for an inner type with NSDMI

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |luigighiron at gmail dot com

--- Comment #9 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
*** Bug 112839 has been marked as a duplicate of this bug. ***