Summary:
This patch implements [P0003R5](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0003r5.html) which removes exception specifications from C++17.
The only changes to the library are removing `set_unexpected`, `get_unexpected`, `unexpected`, and `unexpected_handler`. These functions can be re-enabled in C++17 using `_LIBCPP_ENABLE_CXX17_REMOVED_UNEXPECTED_FUNCTIONS`.
@mclow.lists what do you think about removing stuff is this way?
Reviewers: mclow.lists
Reviewed By: mclow.lists
Subscribers: mclow.lists, cfe-commits
Differential Revision: https://reviews.llvm.org/D28172
llvm-svn: 295406
Summary:
This patch fixes http://llvm.org/PR31938. The description below is copy/pasted from the bug:
The standard says:
template<class charT, class traits = char_traits<charT>,
class Allocator = allocator<charT>>
class basic_string {
using value_type = typename traits::char_type;
// ...
basic_string(const charT* s, const Allocator& a = Allocator());
};
libc++ actually chooses to declare the constructor as
basic_string(const value_type* s, const Allocator& a = Allocator());
The implicit deduction guides from class template argument deduction make what was previously an implementation detail visible:
std::basic_string s = "foo"; // error, can't deduce charT.
The constructor in question is in the libc++ DSO, but fortunately it looks like fixing this will not result in an ABI break.
@rsmith How does this look? I did more than just the constructors mentioned in the PR, but IDK how far to take it.
Reviewers: mclow.lists, rsmith
Reviewed By: rsmith
Subscribers: cfe-commits, rsmith
Differential Revision: https://reviews.llvm.org/D29863
llvm-svn: 295393
On Windows, we were using `Sleep` which is not alertable. This means
that if the thread was used for a user APC or WinProc handling and
thread::sleep was used, we could potentially dead lock. Use `SleepEx`
with an alertable sleep, resuming until the time has expired if we are
awoken early.
llvm-svn: 295329
clang cannot properly handle __declspec and __attribute__ on classes
right now. This prevents the shared_mutex tests from working. Disable
the use of the annotation on COFF targets.
llvm-svn: 294958
Pull in the math functions from ucrt 14+ after auditing the library. It
seems that they are now complete for C99 math. Fixes more windows
tests!
llvm-svn: 294918
The newer versions of ucrt have the math routines. Use the CRT version
to determine if we should include the math routines. Fixes two tests
for Windows.
llvm-svn: 294899
This recommits r294707 with additional fixes. The main difference is
libc++ now correctly builds without any ABI library.
exception.cpp is a bloody mess. It's full of confusing #ifdef branches for
each different ABI library we support, and it's getting unmaintainable.
This patch breaks down exception.cpp into multiple different header files,
roughly one per implementation. Additionally it moves the definitions of
exceptions in new.cpp into the correct implementation header.
This patch also removes an unmaintained libc++abi configuration.
This configuration may still be used by Apple internally but there
are no other possible users. If it turns out that Apple still uses
this configuration internally I will re-add it in a later commit.
See http://llvm.org/PR31904.
llvm-svn: 294730
exception.cpp is a bloody mess. It's full of confusing #ifdef branches for
each different ABI library we support, and it's getting unmaintainable.
This patch breaks down exception.cpp into multiple different header files,
roughly one per implementation. Additionally it moves the definitions of
exceptions in new.cpp into the correct implementation header.
This patch also removes an unmaintained libc++abi configuration.
This configuration may still be used by Apple internally but there
are no other possible users. If it turns out that Apple still uses
this configuration internally I will re-add it in a later commit.
See http://llvm.org/PR31904.
llvm-svn: 294707
Summary:
Libcxx will define its own max_align_t when it is not available. However, the
availability checks today only check for Clang's definition and GCC's
definition. In particular, it does not check for musl's definition, which is the
same as GCC's but guarded with a different macro.
Reviewers: mclow.lists, EricWF
Reviewed By: EricWF
Subscribers: chandlerc, cfe-commits
Differential Revision: https://reviews.llvm.org/D28478
llvm-svn: 294683
A static assertion was misfiring since it checked
is_callable<Visitor, decltype(__variant_alt<T>.value)>. However
the decltype expression doesn't capture the value category as
required. This patch applies extra braces to decltype to fix
that.
llvm-svn: 294612
Different platforms implement the wait/sleep functions in difrerent ways.
It makes sense to externalize this into the threading API.
Differential revision: https://reviews.llvm.org/D29630
Reviewers: EricWF, joerg
llvm-svn: 294573
In addition to the PR for LWG 2773 this patch also ensures
that each of std::ignores constructors or assignment operators
are constexpr.
llvm-svn: 294165
It is my opinion that libc++ should never use `<cassert>`, including in the `dylib`.
This patch remove all uses of `assert` from within libc++ and replaces most of them with `_LIBCPP_ASSERT` instead.
Additionally this patch turn `LIBCXX_ENABLE_ASSERTIONS` off by default,
because the standard library should not be aborting user programs unless explicitly asked to.
llvm-svn: 294107
Visible definitions for basic_string::assign are sometimes emitted in
the dylib depending on the version of LLVM used to compile libc++.
This can cause the check-cxx-abilist target to fail.
This patch attempts marks the basic_string::assign templates as inline
to prevent this. That way the export list is consistent across LLVM
versions.
llvm-svn: 294100
While this change didn't really hurt, it does lead to spurious
warnings about not being able to override weak symbols if you end up
linking objects built with this change to ones built without it.
Furthermore, since __call_once_proxy is called indirectly anyway it
doesn't actually inline ever.
Longer term, it would probably make sense to give this symbol internal
visibility instead.
This reverts r291497
llvm-svn: 293581
These member functions were decorated with `_LIBCPP_FUNC_VIS` when the
class is also decorated with external visibility. This breaks down when
building for PE/COFF, where the member function cannot be decorated if
it is within a decorated class. The class attribute will propagate to
the member. Remove the extraneous decoration.
llvm-svn: 293454
Microsoft's SAL has a `__deref` macro which results in a compilation
failure when building the filesystem module on Windows. Rename the
member function internally to avoid the conflict.
llvm-svn: 293449
This causes unnecessary warnings when building with `cl`. Newer
versions of the C standard permit the redefinition of the macro to the
same value (which is the case here), unfortunately, `cl` does not yet
implement this. Add a check to prevent the redefinition.
llvm-svn: 293439
Many thread-related libc++ test cases fail on FreeBSD, due to the
following -Werror warnings:
In file included from test/std/thread/thread.threads/thread.thread.this/sleep_until.pass.cpp:17:
In file included from include/thread:97:
In file included from include/__mutex_base:17:
include/__threading_support:222:1: error: mutex '__m' is still held at the end of function [-Werror,-Wthread-safety-analysis]
}
^
include/__threading_support:221:10: note: mutex acquired here
return pthread_mutex_lock(__m);
^
include/__threading_support:231:10: error: releasing mutex '__m' that was not held [-Werror,-Wthread-safety-analysis]
return pthread_mutex_unlock(__m);
^
include/__threading_support:242:1: error: mutex '__m' is still held at the end of function [-Werror,-Wthread-safety-analysis]
}
^
include/__threading_support:241:10: note: mutex acquired here
return pthread_mutex_lock(__m);
^
include/__threading_support:251:10: error: releasing mutex '__m' that was not held [-Werror,-Wthread-safety-analysis]
return pthread_mutex_unlock(__m);
^
include/__threading_support:272:10: error: calling function 'pthread_cond_wait' requires holding mutex '__m' exclusively [-Werror,-Wthread-safety-analysis]
return pthread_cond_wait(__cv, __m);
^
include/__threading_support:278:10: error: calling function 'pthread_cond_timedwait' requires holding mutex '__m' exclusively [-Werror,-Wthread-safety-analysis]
return pthread_cond_timedwait(__cv, __m, __ts);
^
6 errors generated.
This is because on FreeBSD, the pthread functions have lock annotations.
Since the functions in __thread_support are internal to libc++ only, add
no_thread_safety_analysis attributes to suppress these warnings.
Reviewers: mclow.lists, EricWF, delesley, aaron.ballman
Reviewed By: aaron.ballman
Subscribers: ed, aaron.ballman, joerg, emaste, cfe-commits
Differential Revision: https://reviews.llvm.org/D28520
llvm-svn: 293197
This reverts commit r292883. Unfortunately <string_view> uses
_LIBCPP_ASSERT in a way which is not compatible with the C++11 dylib
build. I'll investigate more tomorrow.
llvm-svn: 292923
Summary:
It is my opinion that libc++ should never use `<cassert>`, including in the `dylib`. This patch remove all uses of `assert` from within libc++ and replaces most of them with `_LIBCPP_ASSERT` instead.
Additionally this patch turn `LIBCXX_ENABLE_ASSERTIONS` off by default, because the standard library should not be aborting user programs unless explicitly asked to.
Reviewers: mclow.lists, compnerd, smeenai
Reviewed By: mclow.lists
Subscribers: mgorny, cfe-commits
Differential Revision: https://reviews.llvm.org/D29063
llvm-svn: 292883
<string> uses `decltype` in a way incompatible with `__typeof__`.
This is problematic when compiling <string> with Clang 3.4 because
even though it provides `__decltype` libc++ still used `__typeof__`
because clang 3.4 doesn't provide __is_identifier which libc++
uses to detect __decltype.
This patch manually detects Clang 3.4 and properly configures
for it.
llvm-svn: 292833
Summary:
Exactly what the title says.
This patch also adds a `std::hash<nullptr_t>` specialization in C++17, but it was not added by this paper and I can't find the actual paper that adds it.
See http://wg21.link/P0513R0 for more info.
If there are no comments in the next couple of days I'll commit this
Reviewers: mclow.lists, K-ballo, EricWF
Reviewed By: EricWF
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D28938
llvm-svn: 292684
r292564 disabled the aligned new/delete overloads on platforms without
posix_memalign. Unfortunately that patch also disabled the align_val_t
definition in C++17 as well.
This patch causes align_val_t to be exposed in C++17 regardless
of if we have the new/delete overloads.
llvm-svn: 292582
Summary:
This patch disables the aligned new/delet overloads on Apple platforms without `posix_memalign`. This fixes libc++.dylib build regressions on such platforms.
This fixes http://llvm.org/PR31448.
This patch should also be merged into the 4.0 release branch
Reviewers: mclow.lists, rsmith, dexonsmith, jeremyhu
Reviewed By: mclow.lists
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D28931
llvm-svn: 292564
Summary: This patch adjusts the newly added `msvc_stdlib_force_include.hpp` so that it also works when used with `clang++`.
Reviewers: STL_MSFT
Reviewed By: STL_MSFT
Differential Revision: https://reviews.llvm.org/D28917
llvm-svn: 292539
Adding `path::operator=(string_type&&)` made the expression `p = {}`
ambiguous. This path fixes that ambiguity by making the `string&&`
overload a template so it ranks lower during overload resolution.
llvm-svn: 292345
When support for `basic_string_view` was added to string it also
added new assignment operators from `basic_string_view`. These caused
ambiguity when assigning from a braced initializer. This patch fixes
that regression by making the basic_string_view assignment operator
rank lower in overload resolution by making it a template.
llvm-svn: 292276
In order to allow inlining of previously out-of-line functions without an ABI break
libc++ provides legacy definitions in the dylib that old programs can
continue to use. Unfortunatly Windows link.exe detects this hack and diagnoses the duplicate
definitions.
This patch disable the duplicate definitions on Windows by adding an ABI option
which disables all "legacy out-of-line symbols"
llvm-svn: 292190
Moves hot functions such as atomic add into the memory header file
so that they can be inlined, which brings performance benefits.
Patch by Kevin Hu, Aditya Kumar, Sebastian Pop
Differential Revision: https://reviews.llvm.org/D24991
llvm-svn: 292184
MSVC/clang-cl doesn't do a full EBO unless __declspec(empty_bases)
is applied to the derived type. This causes certain tuple tests
to fail.
This patch adds the empty_bases attribute to __tuple_impl in order
for tuple to fully provide the EBO.
llvm-svn: 292159
Summary: On Windows tests that use `_LIBCPP_ASSERT` fail to link because the assertion handler function isn't correctly exported from the libc++ dylib. This patch fixes the dll import/export issues by introducing a new visibility macro `_LIBCPP_EXTERN_VIS` for use on external variables.
Reviewers: compnerd, smeenai, EricWF
Reviewed By: EricWF
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D28728
llvm-svn: 292158
We have already refactored the underlying platform thread type into
__libcpp_thread_t, but there are few places in the source where we
still assume it is an integral type.
This patch refactores those points back into the threading API.
Differential revision: https://reviews.llvm.org/D28608
Reviewers: EricWF
llvm-svn: 292107
When -pedantic-errors is specified `__has_extension(<feature>)` is always
false when it would otherwise be true. This causes C++03 <atomic> to break
along with other issues.
This patch avoids the above problem by using __is_identifier(...) instead since
it is not affected by -pedantic-errors. For example instead of checking for
__has_extension(c_atomics) we now check `!__is_identifier(_Atomic)`, which
is only true when _Atomic is not a keyword provided by the compiler.
This patch applies similar changes to the detection logic for __decltype and
__nullptr as well.
Note that it does not apply this change to the C++03
`static_assert` macro since -Wc11-extensions warnings generated by expanding
that macro will appear in user code, and will not be suppressed as part of a
system header.
llvm-svn: 291995
Clang recently added a `diagnose_if(cond, msg, type)` attribute
which can be used to generate diagnostics when `cond` is a constant
expression that evaluates to true. Otherwise no attribute has no
effect.
This patch adds _LIBCPP_DIAGNOSE_ERROR/WARNING macros which
use this new attribute. Additionally this patch implements
a diagnostic message when a non-const-callable comparator is
given to a container.
Note: For now the warning version of the diagnostic is useless
within libc++ since warning diagnostics are suppressed by the
system header pragma. I'm going to work on fixing this.
llvm-svn: 291961
This tells whether or not the builtin function __builtin_memcmp is constexpr.
Only defined for clang 4.0 and later, and not true for any shipping version of Apple's clang.
llvm-svn: 291773
Although the CriticalSection itself doesnt need to be destroyed, there
may be debug data associated with it. Plug a possible small leak.
llvm-svn: 291536
Summary:
Some parts of the FreeBSD tree are still compiled with C++98, and until
rL288554 this has always worked fine. After that, a complaint about the
newly introduced local _PairT is produced:
/usr/include/c++/v1/memory:3354:27: error: template argument uses local type '_PairT' [-Werror,-Wlocal-type-template-args]
typedef __scalar_hash<_PairT> _HashT;
^~~~~~
/usr/include/c++/v1/memory:3284:29: error: template argument uses local type '_PairT' [-Werror,-Wlocal-type-template-args]
: public unary_function<_Tp, size_t>
^~~
/usr/include/c++/v1/memory:3356:12: note: in instantiation of template class 'std::__1::__scalar_hash<_PairT, 2>' requested here
return _HashT()(__p);
^
As far as I can see, there should be no problem moving the _PairT
struct to just before the __hash_combine() function, which fixes this
particular warning.
Reviewers: mclow.lists, EricWF
Subscribers: cfe-commits, emaste
Differential Revision: https://reviews.llvm.org/D28472
llvm-svn: 291476
Windows is greedy and it defines the identifier `__out` as a macro.
This patch renames all conflicting libc++ identifiers in order
to correctly work on Windows.
llvm-svn: 291345
Add an implementation for the Win32 threading model as a backing API for
the internal c++ threading interfaces. This uses the Fls* family for
the TLS (which has the support for adding termination callbacks),
CRITICAL_SECTIONs for the recursive mutex, and Slim Reader/Writer locks
(SRW locks) for non-recursive mutexes. These APIs should all be
available on Vista or newer.
llvm-svn: 291333
Summary:
On Windows the identifier `__deallocate` is defined as a macro by one of the Windows system headers. Previously libc++ worked around this by `#undef __deallocate` and generating a warning. However this causes the WIN32 version of `__threading_support` to always generate a warning on Windows. This is not OK.
This patch renames all usages of `__deallocate` internally as to not conflict with the macro.
Reviewers: mclow.lists, majnemer, rnk, rsmith, smeenai, compnerd
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D28426
llvm-svn: 291332
This patch adds a libc++ configuration macro for the ABI we
are targeting, either Itanium or Microsoft. For now we configure
for the Microsoft ABI when on Windows with a compiler that defines
_MSC_VER. However this is only temporary until Clang implements
builtin macros we can use.
llvm-svn: 291329
This patch refactors the compiler detection done in `__config` by creating a
set of `_LIBCPP_COMPILER_<TYPE>` macros. The goal of this patch is to make
it easier to detect what compiler is being used outside of `__config`.
Additionally this patch removes workarounds for GCC in `__bit_reference`. I
tested GCC 4.8 and 4.9 without the workaround and neither seemed to need it
anymore.
llvm-svn: 291286
Summary:
This patch attempts to clean up the macro configuration mess in `<__threading_support>`, specifically the mess involving external threading variants. Additionally this patch adds design documentation for `<__threading_support>` and the configuration macros it uses.
The primary change in this patch is separating the idea of an "external API" provided by `<__external_threading>` and the idea of having an external threading library. Now `_LIBCPP_HAS_THREAD_API_EXTERNAL` means that libc++ should use `<__external_threading>` and that the header is expected to exist. Additionally the new macro `_LIBCPP_HAS_THREAD_LIBRARY_EXTERNAL` is now used to configure for using an "external library" with the default threading API.
Reviewers: compnerd, rmaprath
Subscribers: smeenai, cfe-commits, mgorny
Differential Revision: https://reviews.llvm.org/D28316
llvm-svn: 291275
This is motivated by adding a third RTTI scheme to libc++. Split out
the two forms of the itanium RTTI representation. This is based on
suggestions from Eric Fiselier. NFC
llvm-svn: 291174
Split out the recursive and non-recursive mutex. This split is needed
for platforms which may use differing types for the two mutex (e.g.
Win32 threads).
llvm-svn: 291145
Summary:
This patch fixes llvm.org/PR31402 by replacing `map::__find_equal_key` with `__tree::__find_equal`, which has already addressed the same undefined behavior.
Unfortunately I haven't been able to write a test case which causes the UBSAN diagnostic mentioned in the bug report. I can write tests which exercise the UB but for some reason they do not cause UBSAN to fail. Any help writing a test case would be appreciated.
Reviewers: mclow.lists, vsk, EricWF
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D28131
llvm-svn: 291087
In ABI v1 libc++ implements std::pointer_safety as a class type instead
of an enumeration. However this class type does not provide
a default constructor as it should. This patch adds that default constructor.
llvm-svn: 291059
In the C++ standard `std::pointer_safety` is defined
as a C++11 strongly typed enum. However libc++ currently defines
it as a class type which simulates a C++11 enumeration. This
can be detected in valid C++ code.
This patch introduces an the _LIBCPP_ABI_POINTER_SAFETY_ENUM_TYPE ABI option.
When defined `std::pointer_safety` is implemented as an enum type.
Unfortunatly this also means it can no longer be provided as an extension
in C++03.
Additionally this patch moves the definition for `get_pointer_safety()`
out of the dylib, and into the headers. New usages of `get_pointer_safety()`
will now use the inline version instead of the dylib version. However in
order to keep the dylib ABI compatible the old definition is explicitly
compiled into it.
llvm-svn: 291046
The name _LIBCPP_TYPE_VIS_ONLY is no longer accurate because both
_LIBCPP_TYPE_VIS and _LIBCPP_TYPE_VIS_ONLY expand to
__attribute__((__type_visibility__)) with Clang. The only remaining difference
is that _LIBCPP_TYPE_VIS_ONLY can be applied to templates whereas
_LIBCPP_TYPE_VIS cannot (due to dllimport/dllexport not being allowed on
templates).
This patch renames _LIBCPP_TYPE_VIS_ONLY to _LIBCPP_TEMPLATE_VIS.
llvm-svn: 291035
Summary:
This patch attempts to re-implement a fix for LWG 2770, but not the actual specified PR.
The PR for 2770 specifies tuple_size<T const> as only conditionally providing a `::value` member. However C++17 structured bindings require `tuple_size<T const>` to be complete only if `tuple_size<T>` is also complete. Therefore this patch implements only provides the specialization `tuple_size<T CV>` iff `tuple_size<T>` is a complete type.
This fixes http://llvm.org/PR31513.
Reviewers: mclow.lists, rsmith, mpark
Subscribers: mpark, cfe-commits
Differential Revision: https://reviews.llvm.org/D28222
llvm-svn: 291019
MSVC 19+ and clang-cl with emulation version >= 19.00 will provide
char{16,32}_t as builtin types. Adjust the configuration accordingly.
llvm-svn: 290940
Introduce a `_LIBCPP_HAS_BITSCAN64` macro to specify if the 64-bit
variant of the bitscan family of APIs is available. This avoids
duplicating the check in the support header.
llvm-svn: 290924
Replace the use of _WIN32 in libc++. Replace most use with a C runtime
check _LIBCPP_MSVCRT or the new _LIBCPP_WIN32 to indicate that we are
using the Win32 API. Use a new _LIBCPP_WCHAR_IS_UCS2 to indicate that we
are on an environment that has a short wchar_t.
llvm-svn: 290910
after r290850
Before r290850, building libcxx with -DLIBCXX_HAS_EXTERNAL_THREAD_API=ON had two
uses:
- Allow platform vendors to plug-in an __external_threading header which
should take care of the entire threading infrastructure of libcxx
- Allow testing of an externally-threaded library build; where the thread API
is declared using pthread data structures, and the implementation of this
API is provided as a separate library (test/support/external_threads.cpp)
and linked-in when running the test suite.
r290850 breaks the second use case (pthread data structures are no longer
available). This patch re-stores the ability to build+test an
externally-threaded library variant on a pthread based system.
llvm-svn: 290878
Refactor the header to allow us to implement alternate threading models
with alternate data structures. Take the opportunity to clang-format
the area. This will allow us to avoid re-declaring the interfaces for
Win32 threading. NFC
llvm-svn: 290850
This patch implements the correct PR for LWG 2770. It also makes the primary
tuple_size template incomplete again which fixes part of llvm.org/PR31513.
llvm-svn: 290846
Currently libc++ compiles a special version of error_category()
into the dylib. This definition is no longer needed, and doesn't
work on Windows due to dllimport/dllexport semantics.
For those reasons this patch introduces an option to
disable/enable this definition. By default the definition
is provided in ABI v1 except on windows. This patch
also addresses D28210.
llvm-svn: 290840
In the previous fix I used a PMF type as a semi-safe bool type in C++03.
However immediately after committing I realized clang offered explicit
conversion operators as an extension. This patch removes the old fix and
enables _LIBCPP_EXPLICIT using __has_extension instead.
This change also affects the following other classes, which have
'_LIBCPP_EXPLICIT operator bool()'.
* shared_ptr
* unique_ptr
* error_condition
* basic_ios
* function (already C++11 only)
* istream::sentry
* experimental::string_view.
In all of the above cases I believe it is safe to enable the extension, except
in the experimental::string_view case. There seem to be some Clang bugs
affecting the experimental::string_view conversion to std::basic_string. To
work around that I manually disabled _LIBCPP_EXPLICIT in that case.
llvm-svn: 290831
Visual C++ 14 and newer split msvcrt into msvcrt and ucrt with flavours
of the ucrt for different environments. This changed the access to the
ctype table by introducing the `__pctype_func` and `__pwctype_func`
accessors. Use this rather than directly accessing `_ctype` which
allows us to be safer in threaded situations by going through the libc
locking.
llvm-svn: 290823
This is necessary to support cross-compiling a Windows libc++ from
Linux. The CMAKE_SYSTEM_HOST_NAME tells you what, in autotools
parlance, is known as the build as opposed to WIN32 which maps to, in
autotools parlance, host.
llvm-svn: 290800
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.
llvm-svn: 290785
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.
llvm-svn: 290754
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.
llvm-svn: 290750
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
llvm-svn: 290748
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.
llvm-svn: 290662
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.
llvm-svn: 290651
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
llvm-svn: 290503
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.
llvm-svn: 289963
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.
llvm-svn: 289773
Eric Fiselier