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

[Louis Dionne via cfe-dev]

> On Jun 29, 2018, at 20:50, Eric Fiselier <eric at efcs.ca> wrote:
> 
> 
> 
> On Fri, Jun 29, 2018 at 11:18 AM, Louis Dionne via cfe-dev <cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>> wrote:
> 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 <http://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.

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)


> 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.

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20180630/7c213f81/attachment.html>