[libc++] Diagnosing UB when instantiating containers with incomplete types

Hey folks,

Before I ask my question, let me quickly introduce myself since this is my first post. My name's Louis Dionne and I just started a new job where my main focus will be on libc++. I'm also involved in Boost (Boost.Hana), the C++ Standards Committee, and I sometimes go to C++ conferences. I'm very excited about contributing to LLVM and I'm looking forward to interacting with members of the community.

With that being said, I have a simple question about potentially diagnosing the use of incomplete types in standard library containers. As you may know, the Standard currently disallows instantiating most standard library components with incomplete types. If I'm reading this right, it's actually UB to do that. From [res.on.functions] 20.5.4.8/2:

    > In particular, the effects are undefined in the following cases:
    > [...]
    > - if an incomplete type is used as a template argument when
    > instantiating a template component, unless specifically allowed
    > for that component.

libc++ currently does not always warn or trigger a compilation error for such uses. Sometimes it "works", sometimes it doesn't. Does anybody know whether it would be harmful to diagnose this UB by triggering a compilation error when a standard library component that does not allow it is instantiated with an incomplete type?

Specifically, what I'm wondering is whether libc++ actually supports this use case (despite it being banned from the Standard), and users are relying on it. If that were the case, I wouldn't want to break people's code for the sake of blindly sticking more closely to the spec, and we could instead change the Standard to make this use case implementation-defined or even well-defined.

Thoughts?

Cheers,
Louis

Hi Louis,

Even though such behavior is UB, making it work in some cases is nice for third party software which (erroneously) expects it.

For example, take std::dequeue, and this commit:

https://github.com/llvm-mirror/libcxx/commit/746572b91d0b055e56fca202ad5ca34b13fbb084

    Allow deque to handle incomplete types.

    Allow deque and deque::iterator instantiation with incomplete element
    type. This is an ABI breaking change, and it is only enabled if
    LIBCXX_ABI_VERSION >= 2 or LIBCXX_ABI_UNSTABLE=ON.

In this particular case, this is supposed to support software which does something akin to the following (mostly applicable to tree-like data structures):

struct node {
  std::deque<node> children;
};

There may be other examples in libc++ already where incomplete types are sort-of supported. So I would not start throwing compile errors on those right now, maybe an optional warning, enabled by a define.

-Dimitry

Hey folks,

Before I ask my question, let me quickly introduce myself since this is my
first post. My name's Louis Dionne and I just started a new job where my
main focus will be on libc++. I'm also involved in Boost (Boost.Hana), the
C++ Standards Committee, and I sometimes go to C++ conferences. I'm very
excited about contributing to LLVM and I'm looking forward to interacting
with members of the community.

With that being said, I have a simple question about potentially
diagnosing the use of incomplete types in standard library containers. As
you may know, the Standard currently disallows instantiating most standard
library components with incomplete types. If I'm reading this right, it's
actually UB to do that. From [res.on.functions] 20.5.4.8/2:

    > In particular, the effects are undefined in the following cases:
    > [...]
    > - if an incomplete type is used as a template argument when
    > instantiating a template component, unless specifically allowed
    > for that component.

Note that some containers explicitly allow incomplete types. Specifically
forward_list, list, and vector. (See N4510).
IIRC the reason the other node based containers weren't added was because
some implementations were unable
to support such a change without taking an ABI break.

libc++ currently does not always warn or trigger a compilation error for

such uses. Sometimes it "works", sometimes it doesn't. Does anybody know
whether it would be harmful to diagnose this UB by triggering a compilation
error when a standard library component that does not allow it is
instantiated with an incomplete type?

Specifically, what I'm wondering is whether libc++ actually supports this
use case (despite it being banned from the Standard), and users are relying
on it. If that were the case, I wouldn't want to break people's code for
the sake of blindly sticking more closely to the spec, and we could instead
change the Standard to make this use case implementation-defined or even
well-defined.

Yes, libc++ explicitly attempts to support this case and there are users
relying on it. See the `incomplete_type.pass.cpp` tests under
`test/std/containers`.

Normally there is no need to eagerly diagnose incomplete types, as they'll
be diagnosed in their own time when a complete type is actually needed (in
the case of containers),
The problematic cases are those which result in ODR violations, such as
instantiating a type trait twice, with an incomplete type and then later
the completed type.

This is the list I could gather (some of them have requirements on the allocator being a complete allocator):

  • unique_ptr (23.11.1/5)
  • default_delete (23.11.1.1.1/2)
  • shared_ptr (23.11.3/2)
  • weak_ptr (23.11.4/2)
  • enable_shared_from_this (23.11.6/3)
  • atomic<> specializations for smart pointers (23.11.8/1)
  • all the type traits (23.15.2/2)
  • forward_list (26.3.9.1/4)
  • list (26.3.10.1/3)
  • vector (26.3.11.1/3)

Thanks — this is exactly the kind of background information I wanted! In this case, would it make sense to change the Standard so that it is implementation-defined whether template components of the standard library can be instantiated with incomplete types? Or at least the containers?

The current situation is a bit annoying in that it’s technically UB as far as the Standard is concerned, so libc++ letting its users use incomplete types is an invitation for them to get UB on other platforms.

Louis