These exception types are marked with `_LIBCPP_EXCEPTION_ABI` which
expands to `__attribute__((__visibility__("default")))` or
`__declspec(dllexport)`. When building for Windows, we would hit an
error:
cannot apply 'dllexport' to a 'dllexport' class
Remove the duplicate annotations as they will be inherited from the
class.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@290785 91177308-0d34-0410-b5e6-96231b3b80d8
There were two problems with the initial fix.
1. The added tests flushed out that we misconfigured _LIBCPP_EXPLICIT with GCC.
2. Because the boolean type was a member function template it caused weird link
errors. I'm assuming due to the vague linkage rules. This time the bool type
is a non-template member function pointer. That seems to have fixed the
failing tests. Plus it will end up generating less symbols overall, since
the bool type is no longer per instantiation.
original commit message below
-----------------------------
std::basic_ios has an operator bool(). In C++11 and later
it is explicit, and only allows contextual implicit conversions.
However explicit isn't available in C++03 which causes std::istream (et al)
to have an implicit conversion to int. This can easily cause ambiguities
when calling operator<< and operator>>.
This patch uses a "bool-like" type in C++03 to work around this. The
"bool-like" type is an arbitrary pointer to member function type. It
will not convert to either int or void*, but will convert to bool.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@290754 91177308-0d34-0410-b5e6-96231b3b80d8
std::basic_ios has an operator bool(). In C++11 and later
it is explicit, and only allows contextual implicit conversions.
However explicit isn't available in C++03 which causes std::istream (et al)
to have an implicit conversion to int. This can easily cause ambiguities
when calling operator<< and operator>>.
This patch uses a "bool-like" type in C++03 to work around this. The
"bool-like" type is an arbitrary pointer to member function type. It
will not convert to either int or void*, but will convert to bool.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@290750 91177308-0d34-0410-b5e6-96231b3b80d8
Back in r240527 I added a knob to prevent thread-unsafe functions from
being exposed. mblen(), mbtowc() and wctomb() were also added to this
list, as the latest issue of POSIX doesn't require these functions to be
thread-safe.
It turns out that the only circumstance in which these functions are not
thread-safe is in case they are used in combination with state-dependent
character sets (e.g., Shift-JIS). According to Austin Group Bug 708,
these character sets "[...] are mostly a relic of the past and which
were never supported on most POSIX systems".
Though in many cases the use of these functions can be prevented by
using the reentrant counterparts, they are the only functions that allow
you to query whether the locale's character set is state-dependent. This
means that omitting these functions removes actual functionality.
Let's be a bit less pedantic and drop the guards around these functions.
Links:
http://austingroupbugs.net/view.php?id=708http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2037.htm
Reviewed by: ericwf
Differential Revision: https://reviews.llvm.org/D21436
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@290748 91177308-0d34-0410-b5e6-96231b3b80d8
In C++03 libc++ emulates nullptr_t using a class, and #define's nullptr.
However this makes nullptr_t mangle differently between C++03 and C++11.
This breaks any function ABI which takes nullptr_t.
Thanfully Clang provides __nullptr in all dialects. This patch adds
an ABI option to switch to using __nullptr in C++03. In a perfect world
I would like to turn this on by default, since it's just ABI breaking fix
to an ABI breaking bug.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@290662 91177308-0d34-0410-b5e6-96231b3b80d8
This patch implements changes to allow _LIBCPP_ASSERT to throw on failure
instead of aborting. The main changes needed to do this are:
1. Change _LIBCPP_ASSERT to call a handler via a replacable function pointer
instead of calling abort directly. Additionally this patch implements two
handler functions, one which aborts and another that throws an exception.
2. Add _NOEXCEPT_DEBUG macro for disabling noexcept spec on function which
contain _LIBCPP_ASSERT. This is required in order to prevent assertion
failures throwing through a noexcept function. This macro has no effect
unless _LIBCPP_DEBUG_USE_EXCEPTIONS is defined.
Having a non-aborting _LIBCPP_ASSERT is very important to allow sane testing of
debug mode. Currently we can only have one test case per file, since the test
case will cause the program to abort. Testing debug mode this way would require
thousands of test files, most of which would be 95% boiler plate. I don't think
this is a feasible strategy. Fortunately using a throwing debug handler solves
these issues.
Additionally this patch rewrites the documentation for debug mode.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@290651 91177308-0d34-0410-b5e6-96231b3b80d8
It's an internal function and shouldn't be exported. It's also a source
of discrepancy in the published ABI list; these symbols aren't exported
for me on CentOS 7 or Ubuntu 16.04, leading to spurious check-cxx-abilist
failures.
Differential Revision: https://reviews.llvm.org/D27153
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@290503 91177308-0d34-0410-b5e6-96231b3b80d8
When libcxx isn't building with an installed LLVM we copy the libcxx headers into the LLVM build directory so that a clang in that build tree can find the headers relative to itself.
This is only important in situations where you don't have headers installed under /, which is common these days on Darwin.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@289963 91177308-0d34-0410-b5e6-96231b3b80d8
This patch reverts the changes to tuple which fixed construction from
types derived from tuple. It breaks the code mentioned in llvm.org/PR31384.
I'll follow this commit up with a test case.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@289773 91177308-0d34-0410-b5e6-96231b3b80d8
In list::remove we collect the nodes we're removing in a seperate
list instance. However we construct this list using the default
constructor which default constructs the allocator. However allocators
are not required to be default constructible. This patch fixes the
construction of the second list.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@289735 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
The standard requires tuple have the following constructors:
```
tuple(tuple<OtherTypes...> const&);
tuple(tuple<OtherTypes...> &&);
tuple(pair<T1, T2> const&);
tuple(pair<T1, T2> &&);
tuple(array<T, N> const&);
tuple(array<T, N> &&);
```
However libc++ implements these as a single constructor with the signature:
```
template <class TupleLike, enable_if_t<__is_tuple_like<TupleLike>::value>>
tuple(TupleLike&&);
```
This causes the constructor to reject types derived from tuple-like types; Unlike if we had all of the concrete overloads, because they cause the derived->base conversion in the signature.
This patch fixes this issue by detecting derived types and the tuple-like base they are derived from. It does this by creating an overloaded function with signatures for each of tuple/pair/array and checking if the possibly derived type can convert to any of them.
This patch fixes [PR17550]( https://llvm.org/bugs/show_bug.cgi?id=17550)
This patch
Reviewers: mclow.lists, K-ballo, mpark, EricWF
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D27606
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@289727 91177308-0d34-0410-b5e6-96231b3b80d8
This patch removes libc++'s tuple extension which allowed it to be
constructed from fewer initializers than elements; with the remaining
elements being default constructed. However the implicit version of
this extension breaks conforming code. For example:
int fun(std::string);
int fun(std::tuple<std::string, int>);
int x = fun("hello"); // ambigious
Because existing code may already depend on this extension it can be re-enabled
by defining _LIBCPP_ENABLE_TUPLE_IMPLICIT_REDUCED_ARITY_EXTENSION.
Note that the explicit version of this extension is still supported,
although it's somewhat less useful than the implicit one.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@289158 91177308-0d34-0410-b5e6-96231b3b80d8
Reverting because I didn't properly test this patch. Although it's probably
correct to add a stdbool_h module I thought the change fixed more than it did.
I'll re-commit after more investigation.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@288789 91177308-0d34-0410-b5e6-96231b3b80d8
This patch overhalls the libc++ test format/configuration in order to fully support modules. By "fully support" I mean get almost all of the tests passing. The main hurdle for doing this is handling tests that `#define _LIBCPP_FOO` macros to test a different configuration. This patch deals with these tests in the following ways:
1. For tests that define single `_LIBCPP_ABI_FOO` macros have been annotated with `// MODULES_DEFINES: _LIBCPP_ABI_FOO`. This allows the test suite to define the macro on the command line so it uses a different set of modules.
2. Tests for libc++'s debug mode (which define custom `_LIBCPP_ASSERT`) are automatically detected by the test suite and are compiled and run with modules disabled.
This patch also cleans up how the `CXXCompiler` helper class handles enabling/disabling language features.
NOTE: This patch uses `LIT` features which were only committed to LLVM today. If this patch breaks running the libc++ tests you probably need to update LLVM.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@288728 91177308-0d34-0410-b5e6-96231b3b80d8
It's useful to be able to disable visibility annotations entirely; for
example, if we're building libc++ static to include in another library,
and we don't want any libc++ functions getting exported out of that
library. This is a generalization of _LIBCPP_DISABLE_DLL_IMPORT_EXPORT.
Differential Revision: https://reviews.llvm.org/D26934
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@288690 91177308-0d34-0410-b5e6-96231b3b80d8
Previously these hashes were 0 and -1 respectively. These seem like common
sentinel values and should be avoided to prevent needless collisions.
This patch changes those values to different arbitrary numbers, which should
hopefully cause less collisions. Because I couldn't help myself I choose the
fundamental constants for gravity and the speed of light.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@288623 91177308-0d34-0410-b5e6-96231b3b80d8
