[cfe-dev] [libc++] Diagnosing UB when instantiating containers with incomplete types
Dimitry Andric via cfe-dev
cfe-dev at lists.llvm.org
Fri Jun 29 17:12:20 PDT 2018
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
> On 29 Jun 2018, at 19:18, 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.
>
> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 223 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20180630/4898a784/attachment.sig>
More information about the cfe-dev
mailing list