Summary:
A few places in the library seem to behave unexpectedly when the library
is compiled or used with exceptions disabled. For example, not throwing
an exception when a pointer is NULL can lead us to dereference the pointer
later on, which is UB. This patch fixes such occurences.
It's hard to tell whether there are other places where the no-exceptions
mode misbehaves like this, because the replacement for throwing an
exception does not always seem to be abort()ing, but at least this
patch will improve the situation somewhat.
See http://lists.llvm.org/pipermail/libcxx-dev/2019-January/000172.html
Reviewers: mclow.lists, EricWF
Subscribers: christof, jkorous, dexonsmith, libcxx-commits
Differential Revision: https://reviews.llvm.org/D57761
llvm-svn: 353850
to reflect the new license. These used slightly different spellings that
defeated my regular expressions.
We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.
Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.
llvm-svn: 351648
Summary:
We never actually mean to always inline a function -- all the uses of
the macro I could find are actually attempts to control the visibility
of symbols. This is better described by _LIBCPP_INLINE_VISIBILITY, which
is actually always defined the same.
This change is orthogonal to the decision of what we're actually going
to do with _LIBCPP_INLINE_VISIBILITY -- it just simplifies things by
having one canonical way of doing things.
Note that this commit had originally been applied in r336369 and then
reverted in r336382 because of unforeseen problems. Both of these problems
have now been fixed.
Reviewers: EricWF, mclow.lists
Subscribers: christof, dexonsmith, erikvanderpoel
Differential Revision: https://reviews.llvm.org/D48892
llvm-svn: 336866
This reverts commit r336369. The commit had two problems:
1. __pbump was marked as _LIBCPP_EXTERN_TEMPLATE_INLINE_VISIBILITY instead of
_LIBCPP_INLINE_VISIBILITY, which lead to two symbols being added in the
dylib and the check-cxx-abilist failing.
2. The LLDB tests started failing because they undefine
`_LIBCPP_INLINE_VISIBILITY`. I need to figure out why they do that and
fix the tests before we can go forward with this change.
llvm-svn: 336382
Summary:
We never actually mean to always inline a function -- all the uses of
the macro I could find are actually attempts to control the visibility
of symbols. This is better described by _LIBCPP_INLINE_VISIBILITY, which
is actually always defined the same.
This change is orthogonal to the decision of what we're actually going
to do with _LIBCPP_INLINE_VISIBILITY -- it just simplifies things by
having one canonical way of doing things.
Reviewers: EricWF
Subscribers: christof, llvm-commits, dexonsmith, erikvanderpoel, mclow.lists
Differential Revision: https://reviews.llvm.org/D48892
llvm-svn: 336369
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
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
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
Summary:
After putting this question up on cfe-dev I have decided that it would be best to allow the use of `<atomic>` in C++03. Although static initialization is a concern the syntax required to get it is C++11 only. Meaning that C++11 constant static initialization cannot silently break in C++03, it will always cause a syntax error. Furthermore `ATOMIC_VAR_INIT` and `ATOMIC_FLAG_INIT` remain defined in C++03 even though they cannot be used because C++03 usages will cause better error messages.
The main change in this patch is to replace `__has_feature(cxx_atomic)`, which only returns true when C++ >= 11, to `__has_extension(c_atomic)` which returns true whenever clang supports the required atomic builtins.
This patch adds the following macros:
* `_LIBCPP_HAS_C_ATOMIC_IMP` - Defined on clang versions which provide the C `_Atomic` keyword.
* `_LIBCPP_HAS_GCC_ATOMIC_IMP` - Defined on GCC > 4.7. We must use the fallback atomic implementation.
* `_LIBCPP_HAS_NO_ATOMIC_HEADER` - Defined when it is not safe to include `<atomic>`.
`_LIBCPP_HAS_C_ATOMIC_IMP` and `_LIBCPP_HAS_GCC_ATOMIC_IMP` are mutually exclusive, only one should be defined. If neither is defined then `<atomic>` is not implemented and including `<atomic>` will issue an error.
Reviewers: chandlerc, jroelofs, mclow.lists
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D11555
llvm-svn: 245463
If you're crazy enough to want this sort of thing, then add
-D_LIBCPP_HAS_NO_THREADS to your CXXFLAGS and
--param=additiona_features=libcpp-has-no-threads to your lit commnad line.
http://reviews.llvm.org/D3969
llvm-svn: 217271
provided char type other than char or wchar_t. It throw exception during
construction, so there is no chance to imbue own ctype.
This fixes http://llvm.org/bugs/show_bug.cgi?id=13698
llvm-svn: 162648
Louis Dionne