[llvm-dev] [cfe-dev] [RFC][libcxx] Fix and maintain the no-exceptions build of libcxx

[C Bergström via llvm-dev]

On Thu, Oct 29, 2015 at 8:53 PM, Asiri Rathnayake via cfe-dev
<cfe-dev at lists.llvm.org> wrote:
> Hi All,
>
>
>
> libcxx is fairly well designed to work in a no-exceptions environment, with
>
> most of the sources diligently using the _LIBCPP_NO_EXCEPTIONS macro.
> However,
>
> it seems to have bit-rotted a bit and could use some TLC right now. A
>
> no-exceptions variety of libcxx would be quite useful when you want to use
> all
>
> of libcxx goodness without the overhead of exceptions (especially in
> embedded
>
> environments). I'm willing to do the necessary source / test updates and
>
> following is my plan/proposal:
>
>
>
> [Phase-1: Fix the build, setup build-only build bots]
>
>
>
> Currently I cannot build libcxx with -DLIBCXX_ENABLE_EXCEPTIONS=0 due to a
> small
>
> omission in one of the sources. The following patch fixes this:
>
>   http://reviews.llvm.org/D14172
>
> Once we get the reviewed+committed, the next step would be to have some
> build-
>
> bots setup so that we don't regress the build. I've already spoken to Renato
>
> (copied) and he has kindly agreed to setup an ARM build-bot for this.
>
>
>
> @Eric, Dimitri: Would it be possible for you to extend your x86 libcxx
>
> build-bots to include a no-exception build as well?
>
>
>
> Initially, these bots will be build-only. Once I get the tests updated
> (below),
>
> we can enable the test runs too.
>
>
>
> [Phase-2: Fix the tests, update build-bots to run them]
>
>
>
> Currently quite a few tests fail on the no-exceptions libcxx variant build
> as
>
> above. It appears that most of the tests assume that libcxx is built with
>
> exceptions enabled. We'll have to update the tests so that they are aware of
>
> the no-exceptions build as well. I have a work-in-progress patch for this, I
>
> will put it up for review separately once I'm done with it.
>
>
>
> Note that it's not just the tests that need to be updated. For example, take
>
> unordered_map::at(key) definition:
>
>
>
> template <class _Key, class _Tp, class _Hash, class _Pred, class _Alloc>
>
> _Tp& unordered_map<_Key, _Tp, _Hash, _Pred, _Alloc>::at(const key_type& __k)
>
> {
>
>     iterator __i = find(__k);
>
> #ifndef _LIBCPP_NO_EXCEPTIONS
>
>     if (__i == end())
>
>         throw out_of_range("unordered_map::at: key not found");
>
> #endif
>
>     return __i->second;
>
> }
>
>
>
> Here the behavior is not correct w.r.t no-exceptions use case, __i == end()
>
> should instead call abort(). My local patch includes updates to tests as
> well
>
> as fixes for omissions like this one.
>
>
>
> Once this (quite large) patch gets reviewed+committed, we can enable the
> testing
>
> stages of the bots, so that we don't regress the no-exceptions behavior.
>
>
>
> [Phase-3: Add more tests]
>
>
>
> There are quite a few other places in the source which follow the pattern:
>
>
>
> #ifndef _LIBCPP_NO_EXCEPTIONS
>
>   if (check_some_bad_stat())
>
>     throw some_exception()
>
> #endif
>
>   // continues like nothing happened
>
>
>
> I don't think all of those cases are exposed in the current tests, we need
> to
>
> weed-out these cases and add more tests.
>
>
>
>
>
> Does that sound like an OK plan? What do others think about supporting the
>
> no-exceptions libcxx variety long-term? Please let me know.

This looks great from my side - I'm always encouraging users to
disable EH. It's quite annoying in how much it can impact
optimizations.