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

Apologies for the HTML formatted email, fighting my e-mail client....

- Asiri

-------
From: cfe-dev [mailto:cfe-dev-bounces at lists.llvm.org] On Behalf Of Asiri
Rathnayake via cfe-dev
Sent: 29 October 2015 13:54
To: cfe-dev at lists.llvm.org
Cc: llvm-dev at lists.llvm.org
Subject: [cfe-dev] [RFC][libcxx] Fix and maintain the no-exceptions build of
libcxx

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.

Many thanks.

- Asiri