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
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
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
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
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
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
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 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
llvm-svn: 288690
libc++ no longer supports C++11 compilers that don't implement `= default`.
This patch removes all instances of the feature test macro
_LIBCPP_HAS_NO_DEFAULTED_FUNCTIONS as well as the potentially dead code it hides.
llvm-svn: 287321
This is a generalization of `_LIBCPP_NEW_DELETE_VIS`; the new macro name
captures the semantics better, and also allows us to get rid of the
`_WIN32` check in `include/new`. No functional change.
Differential Revision: https://reviews.llvm.org/D26702
llvm-svn: 287164
Create this define in __config and use it elsewhere, instead of checking
the operating system/library defines in other files. The aim is to
reduce the usage of _WIN32 outside __config. No functional change.
Differential Revision: https://reviews.llvm.org/D25741
llvm-svn: 285582
This prevent the symbols from being both externally available and hidden, which
causes them to be linked incorrectly. This is only a problem when the address
of the function is explicitly taken since it will always be inlined otherwise.
This patch fixes the issues that caused r285456 to be reverted, and can
now be reapplied.
llvm-svn: 285531
This patch does two seperate things. First it adds a file called
"__libcpp_version" which only contains the current libc++ version
(currently 4000). This file is not intended for use as a header. This file
is used by Clang in order to easily determine the installed libc++ version.
This allows Clang to enable/disable certain language features only when the
library supports them.
The second change is the addition of _LIBCPP_LIBRARY_VERSION macro, which
returns the version of the installed dylib since it may be different than
the headers.
llvm-svn: 285382
Summary:
Adapt implementation of Library Fundamentals TS optional into an implementation of N4606 optional.
- Update relational operators per http://wg21.link/P0307
- Update to requirements of http://wg21.link/P0032
- Extension: Implement trivial copy/move construction/assignment for `optional<T>` when `T` is trivially copyable.
Audit P/Rs for optional LWG issues:
- 2756 "C++ WP optional<T> should 'forward' T's implicit conversions" Implemented, which also resolves 2753 "Optional's constructors and assignments need constraints" (modulo my refusal to explicitly delete the move operations, which is a design error that I'm working on correcting in the 2756 P/R).
- 2736 "nullopt_t insufficiently constrained" Already conforming. I've added a test ensuring that `nullopt_t` is not copy-initializable from an empty braced-init-list, which I believe is the root intent of the issue, to avoid regression.
- 2740 "constexpr optional<T>::operator->" Already conforming.
- 2746 "Inconsistency between requirements for emplace between optional and variant" No P/R, but note that the author's '"suggested resolution" is already implemented.
- 2748 "swappable traits for optionals" Already conforming.
- 2753 "Optional's constructors and assignments need constraints" Implemented.
Most of the work for this patch was done by Casey Carter @ Microsoft. Thank you Casey!
Reviewers: mclow.lists, CaseyCarter, EricWF
Differential Revision: https://reviews.llvm.org/D22741
llvm-svn: 283980
This patch is largely thanks to Casey Carter @ Microsoft. He did the initial
work of porting our experimental implementation and tests over to namespace
std.
llvm-svn: 283977
Fuchsia is a new operating system which uses musl as the standard
C library, libc++ and libc++abi as the C++ standard library.
Differential Revision: https://reviews.llvm.org/D25414
llvm-svn: 283788
This was caused by r281673, specifically changing `_LIBCPP_EXTERN_TEMPLATE_TYPE_VIS`
from `__attribute__((__type_visibility__("default")))` to
`__attribute__((__visibility("default")))`.
I made that change because I thought the external instantiations needed
their members to have default visibility. However since libc++ never builds
with -fvisibility=hidden this appears not to be needed. Instead this change
caused previously hidden inline methods to become un-hidden, which is a regression.
This patch reverts the problematic change and fixes PR30642.
llvm-svn: 283620
Summary:
The current implementation of `hash_code()` for uniqued RTTI strings violates strict aliasing by dereferencing a type-punned pointer. Specifically it generates a `const char**` pointer from the address of the `__name` member before casting it to `const size_t*` and dereferencing it to get the hash. This is really just a complex and incorrect way of writing `reinterpret_cast<size_t>(__name)`.
This patch changes the conversion sequence so that it no longer contains UB.
Reviewers: howard.hinnant, mclow.lists
Subscribers: rjmccall, cfe-commits
Differential Revision: https://reviews.llvm.org/D24012
llvm-svn: 283408
builds.
On Windows the __declspec(dllimport) and __declspec(dllexport) attributes
require linking to a DLL, not a static library. Previously these annotations
were disabled by default unless _LIBCPP_DLL was defined. However the DLL
configuration is probably the more common one, so it should be supported by
default.
This patch enables import/export attributes by default and adds a
_LIBCPP_DISABLE_DLL_IMPORT_EXPORT macro which can be used to disable this
behavior. If libc++ is built as a static library on Windows then a custom __config
header will be generated that predefines this macro.
This patch is based off work by Shoaib Meenai.
llvm-svn: 282449
Summary:
Libc++ still uses per-feature configuration macros when configuring for C++11. However libc++ requires a feature-complete C++11 compiler so there is no reason to check individual features. This patch starts the process of removing the feature specific macros and replacing their usage with `_LIBCPP_CXX03_LANG`.
This patch removes the __config macros:
* _LIBCPP_HAS_NO_TRAILING_RETURN
* _LIBCPP_HAS_NO_TEMPLATE_ALIASES
* _LIBCPP_HAS_NO_ADVANCED_SFINAE
* _LIBCPP_HAS_NO_DEFAULT_FUNCTION_TEMPLATE_ARGS
* _LIBCPP_HAS_NO_STATIC_ASSERT
As a drive I also changed our C++03 static_assert to use _Static_assert if available.
I plan to commit this without review if nobody voices an objection.
Reviewers: mclow.lists
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D24895
llvm-svn: 282347
Summary:
This patch has been a long time coming (Thanks @eugenis). It changes `_LIBCPP_INLINE_VISIBILITY` to use `__attribute__((internal_linkage))` instead of `__attribute__((visibility("hidden"), always_inline))`.
The point of `_LIBCPP_INLINE_VISIBILITY` is to prevent inline functions from being exported from both the libc++ library and from user libraries. This helps libc++ better manage it's ABI.
Previously this was done by forcing inlining and modifying the symbols visibility. However inlining isn't guaranteed and symbol visibility only affects shared libraries making this an imperfect solution. `internal_linkage` improves this situation by making all symbols local to the TU they are emitted in, regardless of inlining or visibility. IIRC the effect of applying `__attribute__((internal_linkage))` to an inline function is the same as applying `static`.
For more information about the attribute see: http://lists.llvm.org/pipermail/cfe-dev/2015-October/045580.html
Most of the work for this patch was done by @eugenis.
Reviewers: mclow.lists, eugenis
Subscribers: eugenis, cfe-commits
Differential Revision: https://reviews.llvm.org/D24642
llvm-svn: 282345
On Windows, marking an `extern template class` declaration as exported
actually forces an instantiation, which is not the desired behavior.
Instead, the actual explicit instantiations need to be exported.
Differential Revision: https://reviews.llvm.org/D24679
llvm-svn: 281925
Summary:
None of these checks are specific to Android devices. If libc++ was
used with Bionic on a normal Linux system these checks would still be
needed.
Reviewers: mclow.lists, EricWF
Subscribers: compnerd, tberghammer, danalbert, srhines, cfe-commits
Differential Revision: https://reviews.llvm.org/D24690
llvm-svn: 281921
gcc and clang in gcc compatibility mode do not accept __forceinline. Use
the gcc attribute for them instead.
Differential Revision: https://reviews.llvm.org/D24678
llvm-svn: 281766
Summary:
This patch fixes a number of problems with the visibility macros across GCC (on Unix) and Windows (DLL import/export semantics). All of the visibility macros are now documented under `DesignDocs/VisibilityMacros.rst`. Now I'll no longer forget the subtleties of each!
This patch adds two new visibility macros:
* `_LIBCPP_ENUM_VIS` for controlling the typeinfo of enum types. Only Clang supports this.
* `_LIBCPP_EXTERN_TEMPLATE_TYPE_VIS` for redefining visibility on explicit instantiation declarations. Clang and Windows require this.
After applying this patch GCC only emits one -Wattribute warning opposed to 30+.
Reviewers: mclow.lists, EricWF
Subscribers: beanz, mgorny, cfe-commits
Differential Revision: https://reviews.llvm.org/D24602
llvm-svn: 281673
An enum class has associated type info. In the Microsoft ABI, type info
is emitted in the COMDAT section and isn't exported, so clang rightfully
complains about __declspec(dllexport) being unused for an enum class.
On other platforms, we still want to export the type info.
Differential Revision: https://reviews.llvm.org/D24065
llvm-svn: 281264
This patch further decouples libc++ from pthread, allowing libc++ to be built
against other threading systems. There are two main use cases:
- Building libc++ against a thread library other than pthreads.
- Building libc++ with an "external" thread API, allowing a separate library to
provide the implementation of that API.
The two use cases are quite similar, the second one being sligtly more
de-coupled than the first. The cmake option LIBCXX_HAS_EXTERNAL_THREAD_API
enables both kinds of builds. One needs to place an <__external_threading>
header file containing an implementation of the "libc++ thread API" declared
in the <__threading_support> header.
For the second use case, the implementation of the libc++ thread API can
delegate to a custom "external" thread API where the implementation of this
external API is provided in a seperate library. This mechanism allows toolchain
vendors to distribute a build of libc++ with a custom thread-porting-layer API
(which is the "external" API above), platform vendors (recipients of the
toolchain/libc++) are then required to provide their implementation of this API
to be linked with (end-user) C++ programs.
Note that the second use case still requires establishing the basic types that
get passed between the external thread library and the libc++ library
(e.g. __libcpp_mutex_t). These cannot be opaque pointer types (libc++ sources
won't compile otherwise). It should also be noted that the second use case can
have a slight performance penalty; as all the thread constructs need to cross a
library boundary through an additional function call.
When the header <__external_threading> is omitted, libc++ is built with the
"libc++ thread API" (declared in <__threading_support>) as the "external" thread
API (basic types are pthread based). An implementation (pthread based) of this
API is provided in test/support/external_threads.cpp, which is built into a
separate DSO and linked in when running the libc++ test suite. A test run
therefore demonstrates the second use case (less the intermediate custom API).
Differential revision: https://reviews.llvm.org/D21968
Reviewers: bcraig, compnerd, EricWF, mclow.lists
llvm-svn: 281179
Summary:
Currently a number of GCC warnings are emitted when building libc++. This patch fixes or ignores all of them. The primary changes are:
* Work around strict aliasing issues in `typeinfo::hash_code()` by using __attribute__((may_alias)). However I think a non-aliasing `hash_code()` implementation is possible. Further investigation needed.
* Add `_LIBCPP_UNREACHABLE()` to switch in `strstream.cpp` to avoid -Wpotentially-uninitialized.
* Fix -Wunused-value warning in `__all` by adding a void cast.
* Ignore -Wattributes for now. There are a number of real attribute issues when using GCC but enabling the warning is too noisy.
* Ignore -Wliteral-suffix since it warns about the use of reserved identifiers. Note Only GCC 7.0 supports disabling this warning.
* Ignore -Wc++14-compat since it warns about the sized new/delete overloads.
Reviewers: EricWF
Differential Revision: https://reviews.llvm.org/D24003
llvm-svn: 280007
Summary:
This patch attempts to fix the undefined behavior in __hash_table by changing the node pointer types used throughout. The pointer types are changed for raw pointers in the current ABI and for fancy pointers in ABI V2 (since the fancy pointer types may not be ABI compatible).
The UB in `__hash_table` arises because tree downcasts the embedded end node and then deferences that pointer. Currently there are 2 node types in __hash_table:
* `__hash_node_base` which contains the `__next_` pointer.
* `__hash_node` which contains `__hash_` and `__value_`.
Currently the bucket list, iterators, and `__next_` pointers store pointers to `__hash_node` even though they all need to store `__hash_node_base` pointers.
This patch makes that change by introducing a `__next_pointer` typedef which is a pointer to `__hash_node` in the current ABI and `__hash_node_base` afterwards.
One notable change is to the type of `__bucket_list` which used to be defined as `unique_ptr<__node_pointer[], ...>` and is now `unique_ptr<__next_pointer[], ...>` meaning that we now allocate and deallocate different types using a different allocator. I'm going to give this part of the change more thought since it may introduce compatibility issues.
This change is similar to D20786.
Reviewers: mclow.lists, EricWF
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D20787
llvm-svn: 276533
Summary:
This patch attempts to fix the undefined behavior in __tree by changing the node pointer types used throughout. The pointer types are changed for raw pointers in the current ABI and for fancy pointers in ABI V2 (since the fancy pointer types may not be ABI compatible).
The UB in `__tree` arises because tree downcasts the embedded end node and then deferences that pointer. Currently there are 3 node types in __tree.
* `__tree_end_node` which contains the `__left_` pointer. This node is embedded within the container.
* `__tree_node_base` which contains `__right_`, `__parent_` and `__is_black`. This node is used throughout the tree rebalancing algorithms.
* `__tree_node` which contains `__value_`.
Currently `__tree` stores the start of the tree, `__begin_node_`, as a pointer to a `__tree_node`. Additionally the iterators store their position as a pointer to a `__tree_node`. In both of these cases the pointee can be the end node. This is fixed by changing them to store `__tree_end_node` pointers instead.
To make this change I introduced an `__iter_pointer` typedef which is defined to be a pointer to either `__tree_end_node` in the new ABI or `__tree_node` in the current one.
Both `__tree::__begin_node_` and iterator pointers are now stored as `__iter_pointers`.
The other situation where `__tree_end_node` is stored as the wrong type is in `__tree_node_base::__parent_`. Currently `__left_`, `__right_`, and `__parent_` are all `__tree_node_base` pointers. Since the end node will only be stored in `__parent_` the fix is to change `__parent_` to be a pointer to `__tree_end_node`.
To make this change I introduced a `__parent_pointer` typedef which is defined to be a pointer to either `__tree_end_node` in the new ABI or `__tree_node_base` in the current one.
Note that in the new ABI `__iter_pointer` and `__parent_pointer` are the same type (but not in the old one). The confusion between these two types is unfortunate but it was the best solution I could come up with that maintains the ABI.
The typedef changes force a ton of explicit type casts to correct pointer types and to make current code compatible with both the old and new pointer typedefs. This is the bulk of the change and it's really messy. Unfortunately I don't know how to avoid it.
Please let me know what you think.
Reviewers: howard.hinnant, mclow.lists
Subscribers: howard.hinnant, bbannier, cfe-commits
Differential Revision: https://reviews.llvm.org/D20786
llvm-svn: 276003
This patch does the following:
* It renames `_LIBCPP_TRIVIAL_PAIR_COPY_CTOR` to `_LIBCPP_DEPRECATED_ABI_DISABLE_PAIR_TRIVIAL_COPY_CTOR`.
* It automatically enables this option on FreeBSD in ABI V1, since that's the current ABI FreeBSD ships.
* It cleans up the handling of this option in `std::pair`.
I would like the sign off from the FreeBSD maintainers. They will no longer need to keep their `__config` changes downstream.
I'm still hoping to come up with a better way to maintain the ABI without needing these constructors.
Reviewed in https://reviews.llvm.org/D21329
llvm-svn: 275749
This patch adds the weak_type typedef in shared_ptr. It is available in
C++17 and newer.
This patch also updates the _LIBCPP_STD_VER and TEST_STD_VER macros to
have the value of 16, since 2016 is the current year.
llvm-svn: 273839
Summary:
This patch implements the variadic `lock_guard` paper.
Making `lock_guard` variadic is a ABI breaking change because the specialization `lock_guard<_Mutex>` mangles differently then when it was the primary template. This change only provides variadic `lock_guard` in ABI V2 or when `_LIBCPP_ABI_VARIADIC_LOCK_GUARD` is defined.
Note that in ABI V2 `lock_guard` must always be declared as a variadic template, even in C++03, in order to keep the ABI consistent. For this reason `lock_guard` is forward declared as a variadic template in all standard dialects and therefore depends on variadic templates being provided as an extension in C++03. All supported versions of Clang and GCC provide this extension.
Reviewers: mclow.lists
Subscribers: K-ballo, mclow.lists, cfe-commits
Differential Revision: http://reviews.llvm.org/D21260
llvm-svn: 272634
The existing pthread detection code in __config is pretty good for
common operating systems. It doesn't allow cmake-time choices to be
made for uncommon operating systems though.
This change adds the LIBCXX_HAS_PTHREAD_API cmake flag, which turns
into the _LIBCPP_HAS_THREAD_API_PTHREAD preprocessor define. This is
a name change from the old _LIBCPP_THREAD_API_PTHREAD. The lit tests
want __config_site.in variables to have a _LIBCPP_HAS prefix.
http://reviews.llvm.org/D20573
llvm-svn: 270735
This patch extracts out all the pthread dependencies of libcxx into the
new header __threading_support. The motivation is to make it easy to
re-target libcxx into platforms that do not support pthread.
Original patch from Fulvio Esposito (fulvio.esposito@outlook.com) - D11781
Applied with tweaks - D19412
Change-Id: I301111f0075de93dd8129416e06babc195aa936b
llvm-svn: 268734
Summary:
when setting LIBCXX_ENABLE_EXCEPTIONS=false, _LIBCPP_NO_EXCEPTIONS wil be defined in both commandline and _config
Reviewers: bcraig, EricWF
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D19344
llvm-svn: 266956
This patch is fairly large and contains a number of changes. The changes all work towards
allowing __tree to properly handle __value_type esspecially when inserting into the __tree.
I chose not to break this change into smaller patches because it wouldn't be possible to
write meaningful standard-compliant tests for each patch.
It is very similar to r260513 "[libcxx] Teach __hash_table how to handle unordered_map's __hash_value_type".
Changes in <map>
* Remove __value_type's constructors because it should never be constructed directly.
* Make map::emplace and multimap::emplace forward to __tree and remove the old definitions
* Remove "__construct_node" map and multimap member functions. Almost all of the construction is done within __tree.
* Fix map's move constructor to access "__value_type.__nc" directly and pass this object to __tree::insert.
Changes in <__tree>
* Add traits to detect, handle, and unwrap, map's "__value_type".
* Convert methods taking "value_type" to take "__container_value_type" instead. Previously these methods caused
unwanted implicit conversions from "std::pair<Key, Value>" to "__value_type<Key, Value>".
* Delete __tree_node and __tree_node_base's constructors and assignment operators. The node types should never be constructed
because the "__value_" member of __tree_node must be constructed directly by the allocator.
* Make the __tree_node_destructor class and "__construct_node" methods unwrap "__node_value_type" into "__container_value_type" before invoking the allocator. The user's allocator can only be used to construct and destroy the container's value_type. Passing it map's "__value_type" was incorrect.
* Cleanup the "__insert" and "__emplace" methods. Have __insert forward to an __emplace function wherever possible to reduce
code duplication. __insert_unique(value_type const&) and __insert_unique(value_type&&) forward to __emplace_unique_key_args.
These functions will not allocate a new node if the value is already in the tree.
* Change the __find* functions to take the "key_type" directly instead of passing in "value_type" and unwrapping the key later.
This change allows the find functions to be used without having to construct a "value_type" first. This allows for a number
of optimizations.
* Teach __move_assign and __assign_multi methods to unwrap map's __value_type.
llvm-svn: 264986
This adds clang thread safety annotations to std::mutex and
std::lock_guard so code using these types can use these types directly
instead of having to wrap the types to provide annotations. These checks
when enabled by -Wthread-safety provide simple but useful static
checking to detect potential race conditions.
See http://clang.llvm.org/docs/ThreadSafetyAnalysis.html for details.
This patch was reviewed in http://reviews.llvm.org/D14731.
llvm-svn: 263611
This patch is fairly large and contains a number of changes. The main change
is teaching '__hash_table' how to handle '__hash_value_type'. Unfortunately
this change is a rampant layering violation, but it's required to make
unordered_map conforming without re-writing all of __hash_table.
After this change 'unordered_map' can delegate to '__hash_table' in almost all cases.
The major changes found in this patch are:
* Teach __hash_table to differentiate between the true container value type
and the node value type by introducing the "__container_value_type" and
"__node_value_type" typedefs. In the case of unordered_map '__container_value_type'
is 'pair<const Key, Value>' and '__node_value_type' is '__hash_value_type'.
* Switch almost all overloads in '__hash_table' previously taking 'value_type'
(AKA '__node_value_type) to take '__container_value_type' instead. Previously
'pair<K, V>' would be implicitly converted to '__hash_value_type<K, V>' because
of the function signature.
* Add '__get_key', '__get_value', '__get_ptr', and '__move' static functions to
'__key_value_types'. These functions allow '__hash_table' to unwrap
'__node_value_type' objects into '__container_value_type' and its sub-parts.
* Pass '__hash_value_type::__value_' to 'a.construct(p, ...)' instead of
'__hash_value_type' itself. The C++14 standard requires that 'a.construct()'
and 'a.destroy()' are only ever instantiated for the containers value type.
* Remove '__hash_value_type's constructors and destructors. We should never
construct an instance of this type.
(TODO this is UB but we already do it in plenty of places).
* Add a generic "try-emplace" function to '__hash_table' called
'__emplace_unique_key_args(Key const&, Args...)'.
The following changes were done as cleanup:
* Introduce the '_LIBCPP_CXX03_LANG' macro to be used in place of
'_LIBCPP_HAS_NO_VARIADICS' or '_LIBCPP_HAS_NO_RVALUE_REFERENCE'.
* Cleanup C++11 only overloads that assume an incomplete C++11 implementation.
For example this patch removes the __construct_node overloads that do
manual pack expansion.
* Forward 'unordered_map::emplace' to '__hash_table' and remove dead code
resulting from the change. This includes almost all
'unordered_map::__construct_node' overloads.
The following changes are planed for future revisions:
* Fix LWG issue #2469 by delegating 'unordered_map::operator[]' to use
'__emplace_unique_key_args'.
* Rewrite 'unordered_map::try_emplace' in terms of '__emplace_unique_key_args'.
* Optimize '__emplace_unique' to call '__emplace_unique_key_args' when possible.
This prevent unneeded allocations when inserting duplicate entries.
The additional follow up work needed after this patch:
* Respect the lifetime rules for '__hash_value_type' by actually constructing it.
* Make '__insert_multi' act similar to '__insert_unique' for objects of type
'T&' and 'T const &&' with 'T = __container_value_type'.
llvm-svn: 260513
Shoaib Meenai