[libcxx-dev] Advancing libc++ Beyond C++03

[Eric Fiselier via libcxx-dev]

On Mon, Jun 10, 2019 at 9:27 PM JF Bastien <jfbastien at apple.com> wrote:

>
>
> On Jun 10, 2019, at 6:10 PM, Eric Fiselier <eric at efcs.ca> wrote:
>
> 
> Yes, fixing these ABI bugs would require an ABI change. I don't know of
> ABI bugs in standard C++03 components,
>
> I'm not sure how many users actually depend on our C++11 extensions in
> C++03. Or how many of those people mix
> different C++ dialects in the same binary.
>
> My sense is that having a different ABI between C++11 and C++03 is worse
> than breaking ABI compatibility once to fix that.
>
> In the case of  `std::function::operator()(...)`, the  C++03
> implementation passes rvalues across the type-erasure boundary
> by value, C++11 passes by rvalue reference. If both versions of the vtable
> appear in your program than you've got problems.
>
> It's less clear if  deleting <__nullptr> emulation is as palatable for all
> parties. I could imagine a user writing a declaration
> that contains `std::nullptr_t` in the mangling.
>
>
>
> Ok thanks, that answers one of my questions: the C++03 extensions would
> break ABI. Would your suggested change affect compliant C++03 ABI?
>

No, it would have no effect on the "compliant C++03 ABI`.


>
> Breaking extensions seems less bad... but it’s reminiscent of the
> std::experimental discussion: what expectations have we given developers
> when using extensions? If we break ABI on just extensions, can we diagnose
> the breakage? Or just drop the extension (maybe keep it behind a flag,
> deprecate, etc)?
>

We'll also be improving their QoI significantly at the same time. Our
non-variadic fallbacks are of poor quality.

I'm unsure what expectations we've given developers that user these
extensions, I'm actually not aware of any users.

We could diagnose the breakage, Or we could re-create the C++03 ABI in the
variadic version of `std::function`.
Either way, I would   get to delete <__functional_base_03> and
`<__functional_03>`.

I think we should have a separate conversation about if we can drop the
extensions, and how we would manage that.



> Sorry for asking so many questions! In general I agree that shedding
> burden is useful, but I want to understand the caveats (if any). Maybe that
> can inform future extensions too :)
>
>
> /Eric
>
> On Mon, Jun 10, 2019 at 6:03 PM JF Bastien <jfbastien at apple.com> wrote:
>
>>
>>
>> On Jun 10, 2019, at 1:37 PM, Eric Fiselier via libcxx-dev <
>> libcxx-dev at lists.llvm.org> wrote:
>>
>> Hello,
>>
>> libc++ claims to support GCC with C++03 ("G++03"), and this is a problem
>> for our users.
>>
>> Our C++03 users are all using Clang. They must be.  Less than 9% of the
>> C++03 tests pass with GCC [1][2]. No non-trivial C++ program could work.
>>
>> Attempting to support G++03 impacts our QoI considerably. Unlike Clang,
>> G++03 offers almost no C++11 extensions. If we could remove all the
>> fallbacks for G++03, it would mean libc++ could::
>>
>> * Improve Correctness:
>>
>> Every `#ifdef _LIBCPP_HAS_NO_<C++11-feature>` is a bug manifest. It
>> exists to admit for deviant semantics.
>>
>> * Achieve ABI stability between C++03 and C++11
>>
>> Differences between our C++03 and C++Rest branches contain ABI bugs. For
>> example `std::nullptr_t` and `std::function::operator()(...)` are currently
>> incompatible between C++11 and C++03, but could be fixed.
>>
>>
>>
>> Would we break ABI of C++03 using clang as a compiler? Would we only do
>> so for STL features which aren’t actually part of C++03 anyways?
>>
>>
>> * Decrease Compile Times and Memory Usage:
>>
>>
>> Writing efficient SFINAE requires C++11. Using alias templates, libc++
>> could reduce the number of instantiations it produces substantially.
>>
>> * Decrease Binary Size
>>
>>
>> Similar to the last point, G++03 forces metaprogramming techniques that
>> emit more debug information [3] [4]. Compared to libstdc++, debug
>> information size increases of +10% are not uncommon.
>>
>>
>> I would like the communities blessing to officially unsupport GCC in
>> C++03 in the 9.0 release.
>>
>> /Eric
>>
>> [1] https://gist.github.com/EricWF/83b352471c999655859f75f60c9061a8
>> [2] Clang and GCC are our only "supported" C++03 compilers. MSVC and XLC
>> don't support C++03, we don't support ILC.
>> [3] G++03 disallows default template parameters, so SFINAE must be
>> written as default function parameters. Function parameters create live
>> variables, live variables force debug info emission for their type, which
>> emits debug information for the SFINAE construct.
>> [4] Unlike C++03 metafunctions written with normal class templates, C++11
>> alias templates aren't instantiated at every use.
>>
>>
>> _______________________________________________
>> libcxx-dev mailing list
>> libcxx-dev at lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/libcxx-dev
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/libcxx-dev/attachments/20190610/63e787ad/attachment-0001.html>