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
Eric Fiselier