clang fails to compile apparently valid C++ code with forward declared/incomplete types

[leonleon77]

Hi, there is thinking that it could be a bug in Clang (tried with 15 as well as trunk).
Original discussion as per
https://gcc.gnu.org/pipermail/gcc-help/2022-December/142044.html
and
https://gcc.gnu.org/pipermail/gcc-help/2022-December/142047.html

the code below reproduces the issue (GCC 12.2 -std=c++20 compiles fine, MSVC19.33 /std:c++20 compiles fine, Clang 15.0.0 and trunk -std=c++20 barf)

#include <memory>
#include <vector>
#include <optional>

struct X;

template <typename T>
struct J {
    typedef typename T::x aoeu;
};

struct S {
    ::std::vector<::std::shared_ptr<J<X>>> v;
};

static ::std::optional<S> opt;

struct X {
    typedef int x;
};

int main () {
}

Clang barfs with: incomplete type 'X' named in nested name specifier typedef typename T::x aoeu (if one makes struct X a template the textual error changes but semantics remain the same more or less)...

Interestingly if S::v is not a vector, i.e. instead of
::std::vector<::std::shared_ptr<J>> v;
v is just
::std::shared_ptr<J> v;

... then clang compiles fine.

The thoughts on GCC email list are that since no instantiation takes place (shared_ptr) then the code should compile.

As LIU Hao comments in that second link above: I think this is a bug in Clang. Instantiation of shared_ptr<T<U>> is not meant to instantiate T<U>. Your code actually compiles fine if the definition of J was not provided.

Kind regards
Leon

[llvmbot]

@llvm/issue-subscribers-clang-frontend

[llvmbot]

@llvm/issue-subscribers-c-20

[shafik]

Interesting to note that if compiled with -stdlib=libc++ clang is ok: https://godbolt.org/z/zbY1T8E3T

[shafik]

I believe this is undefined as per res.on.functions:

In particular, the behavior is undefined in the following cases:
...
If an incomplete type ([basic.types.general]) is used as a template argument when instantiating a template component or evaluating a concept, unless specifically allowed for that component.

I will leave some time for others to chime in since I am not 100% sure.

[leonleon77]

I believe this is undefined as per res.on.functions:

In particular, the behavior is undefined in the following cases:
...
If an incomplete type ([basic.types.general]) is used as a template argument when instantiating a template component or evaluating a concept, unless specifically allowed for that component.

I wonder if (say since c++17) the std::vector would be among those 'allowed for' components? I dont have the explicit standard-link ready, other than may be https://timsong-cpp.github.io/cppwp/n4861/vector.overview#4 which reads

An incomplete type T may be used when instantiating vector if the allocator meets the allocator completeness requirements. T shall be complete before any member of the resulting specialization of vector is referenced.

... but even from https://en.cppreference.com/w/cpp/container/vector we would have

"This container (but not its members) can be instantiated with an incomplete element type if the allocator satisfies the allocator completeness requirements"

... and as for shared_ptr (element type of vector in the issue at hand) we would have similar from https://en.cppreference.com/w/cpp/memory/shared_ptr

"std::shared_ptr may be used with an incomplete type T"

(albeit with some caveats).

[leonleon77]

ah! may be its the

but not its members

in the vector docs that is the trigger for UB -- if std::optional implementation, in its ctor, is referencing vector's members (e.g. ctor/dtor etc.)... now, on to the std::optional specs to find out what may or may not be 'incomplete' during its instantiation :) I'll do some more reading :)

[leonleon77]

ok thanks to Jonathan Wakely for clarifying at https://gcc.gnu.org/pipermail/gcc-help/2022-December/142055.html I think it is just a bug/UB in the original code (namely in using std::optional with incomplete, nested, type).
Happy to close this off.

[leonleon77]

Sorry, the closure might have been premature (I might have read Jonathan's comments out of context in this specific case).

As Liu Hao points out at https://gcc.gnu.org/pipermail/gcc-help/2022-December/142061.html and https://gcc.gnu.org/pipermail/gcc-help/2022-December/142058.html

We basically have the following:

(1) the only thing instantiated verbosely in the original code sample is static ::std::optional<S> opt and

(2) I am told that 'S' at that point is indeed to be considered a complete type (even though its data members are of vector and its elemnt type shared_ptr has its own incomplete type, X, specified up to that point; but because standard allows vec and shared_ptr to be instantiated with incomplete type then the outer type is I am told indeed complete).

... but if this is the case then there is no UB... thoughts?

@EugeneZelenko not sure if the issue needs to be re-opened or whether it will still be visible to others 'as is'...