<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jun 29, 2018 at 11:18 AM, Louis Dionne via cfe-dev <span dir="ltr"><<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hey folks,<br>
<br>
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.<br>
<br>
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] <a href="http://20.5.4.8/2" rel="noreferrer" target="_blank">20.5.4.8/2</a>:<br>
<br>
    > In particular, the effects are undefined in the following cases:<br>
    > [...]<br>
    > - if an incomplete type is used as a template argument when<br>
    >   instantiating a template component, unless specifically allowed<br>
    >   for that component.<br>
<br></blockquote><div><br></div><div><br></div><div>Note that some containers explicitly allow incomplete types. Specifically forward_list, list, and vector. (See N4510).<br></div><div>IIRC the reason the other node based containers weren't added was because some implementations were unable</div><div>to support such a change without taking an ABI break.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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?</blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
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.<br></blockquote><div><br></div><div>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`.</div><div><br></div><div>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),</div><div>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.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Thoughts?<br>
<br>
Cheers,<br>
Louis<br>
<br>
______________________________<wbr>_________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/cfe-dev</a><br>
</blockquote></div><br></div></div>