Summary:
This patch improves how libc++ handles min/max macros within the headers. Previously libc++ would undef them and emit a warning.
This patch changes libc++ to use `#pragma push_macro` to save the macro before undefining it, and `#pragma pop_macro` to restore the macros and the end of the header.
Reviewers: mclow.lists, bcraig, compnerd, EricWF
Reviewed By: EricWF
Subscribers: cfe-commits, krytarowski
Differential Revision: https://reviews.llvm.org/D33080
llvm-svn: 304357
Clang started providing -fcoroutines and defining __cpp_coroutines
way before it implemented the __builtin_coro_foo functions. This
means that simply checking if __cpp_coroutines is not a sufficient
way of detecting the actual feature.
This patch implements _LIBCPP_HAS_NO_COROUTINES which implements
a slightly more complex feature check. Specifically it requires
__cpp_coroutines >= 201703L, which only holds for Clang 5.0 built
after 2017/05/24.
llvm-svn: 303956
Some MinGW configurations use WinPThread instead of the native
threading interfaces. When this happens libc++ doesn't build because
it tries to use the wrong threading API.
This patch attempts to correctly detect and enable pthreads; Selecting
them when __MINGW32__ is defined and __has_include(<pthread.h>) is true.
I'm not sure if this works correctly 100% of the time but it seemed
like the most correct approach available.
llvm-svn: 302734
Libc++ is used as a system library on macOS and iOS (amongst others). In order
for users to be able to compile a binary that is intended to be deployed to an
older version of the platform, clang provides the
availability attribute <https://clang.llvm.org/docs/AttributeReference.html#availability>_
that can be placed on declarations to describe the lifecycle of a symbol in the
library.
See docs/DesignDocs/AvailabilityMarkup.rst for more information.
Differential Revision: https://reviews.llvm.org/D31739
llvm-svn: 302172
Fuchsia's libc was forked from musl, but has evolved sufficiently
since then so it no longer makes sense to pretend it's musl. This
change implements direct support for Fuchsia rather than
piggybacking on musl support.
Differential Revision: https://reviews.llvm.org/D31970
llvm-svn: 300261
When the libc++ extern template macros were added, the intent was for it
to be possible for consumers of the headers to disable extern templates
(via `-D_LIBCPP_EXTERN_TEMPLATE(...)=`). Unfortunately, support for
specifying function-like macros varies on the command line varies across
compilers (e.g. MSVC doesn't support it at all), and cmake doesn't allow
it for the same reason. Add a non-function macro for this purpose.
The intended use is for libraries which want to use the libc++ headers
without taking a dependency on the libc++ library itself. I can name the
macro something which reflects its intent rather than its behavior (e.g.
`_LIBCPP_HEADER_ONLY`) if desired.
Differential Revision: https://reviews.llvm.org/D31725
llvm-svn: 300246
The inline function definition ABI macro is gated on COFF dllexport
semantics, so it's more appropriate to mark it with the object file
format macro rather than the generic _WIN32 macro. We now have no uses
of _WIN32 apart from those used to define the other Windows macros :)
Clarify the ABI macro comment and make the object file format check
exhaustive while I'm here.
llvm-svn: 300097
r145698 introduced _LIBCPP_HAS_NO_STRONG_ENUMS by copy-pasting the
__has_feature check from objc_arc_weak/_LIBCPP_HAS_OBJC_ARC_WEAK, and
accidentally started defining _LIBCPP_HAS_NO_STRONG_ENUMS whenever
__has_feature(objc_arc_weak). This is totally bogus, and means that
Libc++ thinks Objective-C++ compilations with -fobjc-arc don't have
strong enums.
Delete the accidental line.
I thought about adding a test, but it would be entirely duplicative of
the patch (if has-feature strong enums, check that has-no-strong-enums
is not defined).
llvm-svn: 299236
Summary:
bad_function_call is currently an empty class, so any object files using
that class will end up with their own copy of its typeinfo, typeinfo
name and vtable, leading to unnecessary duplication that has to be
resolved by the dynamic linker. Instead, give bad_function_call a key
function and put a definition for that key function in libc++ itself, to
centralize the typeinfo and vtable.
This is consistent with the behavior for other exception classes. The
key functions are defined in libc++ rather than libc++abi since the
class is defined in the libc++ versioning namespace, so ABI
compatibility with libstdc++ is not a concern.
Guard this change behind an ABI macro, since it isn't backwards
compatible (i.e., clients built against the new libc++ headers wouldn't
be able to run against an older libc++ library).
Reviewers: mclow.lists, EricWF
Subscribers: mgorny, cfe-commits
Differential Revision: https://reviews.llvm.org/D27387
llvm-svn: 298937
Put proper guards around _LIBCPP_METHOD_TEMPLATE_IMPLICIT_INSTANTIATION_VIS.
No functional change on non-Windows. Avoids incorrect macro redefinition
on Windows.
llvm-svn: 297330
Summary:
Most classes annotated with _LIBCPP_TYPE_VIS need to have at least some
of their members exported, otherwise we have a lot of link errors when
linking against a libc++ built with hidden visibility. This also makes
_LIBCPP_TYPE_VIS be consistent across platforms, since on Windows it
already exports members.
With this change made, any template methods of a class marked
_LIBCPP_TYPE_VIS will also get default visibility when instantiatied,
which is not desirable for clients of libc++ headers who wish to control
their visibility; this is the same issue as PR30642. Annotate all
problematic methods with an explicit visibility specifier to avoid this.
The problematic methods were found by running bad-visibility-finder [1]
against the libc++ headers after making the _LIBCPP_TYPE_VIS change. The
small methods were marked for inlining; the larger ones hidden.
[1] https://github.com/smeenai/bad-visibility-finder
Reviewers: mclow.lists, EricWF
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D25208
llvm-svn: 296732
When building libc++ with hidden visibility, we want explicit template
instantiations to export members. This is consistent with existing
Windows behavior, and is necessary for clients to be able to link
against a hidden visibility built libc++ without running into lots of
missing symbols.
An unfortunate side effect, however, is that any template methods of a
class with an explicit instantiation will get default visibility when
instantiated, unless the methods are explicitly marked inline or hidden
visibility. This is not desirable for clients of libc++ headers who wish
to control their visibility, and led to PR30642.
Annotate all problematic methods with an explicit visibility specifier
to avoid this. The problematic methods were found by running
https://github.com/smeenai/bad-visibility-finder against the libc++
headers after making the _LIBCPP_EXTERN_TEMPLATE_TYPE_VIS change. The
methods were marked with the new _LIBCPP_METHOD_TEMPLATE_IMPLICIT_INSTANTIATION_VIS
macro, which was created for this purpose.
It should be noted that _LIBCPP_EXTERN_TEMPLATE_TYPE_VIS was originally
intended to expand to default visibility, and was changed to expanding
to default type visibility to fix PR30642. The visibility macro
documentation was not updated accordingly, however, so this change makes
the macro consistent with its documentation again, while explicitly
fixing the methods which resulted in that PR.
Differential Revision: https://reviews.llvm.org/D29157
llvm-svn: 296731
GCC 7.0.1 started warning that __attribute__((__strong__)) is depricated.
This patch switches to using inline namespace with GCC instead. I believe
this wasn't done originally in order to support older GCC versions w/o
support for inline namespaces, or because earlier versions of GCC warned
users that the STL was using an inline namespace (even though it shouldn't affect users).
However I believe all of the above problems are gone for GCC 4.9 and greater.
Therefore switching to using inline namespaces instead of using __strong__
is the most correct behavior.
llvm-svn: 295428
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
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
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
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
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:
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
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
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
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
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
Eric Fiselier