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

[Eric Fiselier via cfe-dev]

On Fri, Jun 29, 2018 at 11:18 AM, Louis Dionne via cfe-dev <
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:
>
>     > 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.



>
> Thoughts?
>
> Cheers,
> Louis
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20180629/c06489db/attachment.html>