Block.h is a pretty common name, which can lead to nasty collisions with
user provided headers. Since we're only getting a few simple declarations
from the header, it's better to declare them manually than to include the
header.
rdar://66384326
Differential Revision: https://reviews.llvm.org/D85035
Summary: In std::functional moves the reference out of the `__callable` implementation and replaces `_EnableIfCallable` with `_EnableIfLValueCallable` (`_EnableIfLValueCallable` passes `__callable` an lvalue reference type).
Reviewers: ldionne, #libc!
Subscribers: dexonsmith, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D80071
This patch adds `_VSTD::` to some calls to `make_pair` inside the
implementations of searchers, to prevent things exploding if there is
a make_pair in an associated namespace of a user-defined type.
https://godbolt.org/z/xAFG98
Differential Revision: https://reviews.llvm.org/D72640
The runtime for Blocks may not be available even though the Blocks
language extension _is_ available. Instead of potentially failing,
this commit is much more conservative and assumes the runtime for
Blocks is only provided on Apple platforms.
Differential Revision: https://reviews.llvm.org/D78757
Due to Clang bug http://llvm.org/PR45151, deprecated attributes are not
picked up on partial specializations. This patch instead applies it to
the first declaration of std::function itself.
There are a handful of standard library types that are intended
to support CTAD but don't need any explicit deduction guides to
do so.
This patch adds a dummy deduction guide to those types to suppress
-Wctad-maybe-unsupported (which gets emitted in user code).
llvm-svn: 367770
The new meta-programming primitives are lower cost than the old versions. This patch removes those old versions and switches libc++ to use the new ones.
llvm-svn: 364160
When applied to a typedef or alias template, the [[nodebug]] attribute
makes the typedef transparent to the debugger, so instead of seeing
`std::__function::__alloc_func<remove_reference<void(&)()>::type,
allocator<remove_reference<void(&)()>, void()>::_Target` you see
`void(&)()` as the type of the variable in your debugger.
Removing all this SFINAE noise from debug info has huge binary size
wins, in addition to improving the readability.
For now this change is on by default. Users can override it by
specifying -D_LIBCPP_NODEBUG_TYPE=
llvm-svn: 363117
std::function uses a standard allocator to manage its memory, however
standard allocators are templates and using them correctly requires
a stupid amount of instantiations. This leads to a substantial increase
in debug info and object sizes.
This patch addresses the issue by dropping the allocator when possible
and using raw new and delete to get memory.
This change decreases the object file size for the test func.wrap.func.con/F.pass.cpp by 33% and the final binary by 29% (when compiled with -g -ggnu-pubnames -gpubnames).
It also roughly halfs the number of entries in the pubnames and pubtype
sections.
llvm-svn: 362865
On my Windows system, __allocator is defined to nothing. This change fixes build errors of the below form:
In file included from algorithm:644:
functional(1492,31): error: expected member name or ';' after declaration specifiers
const _Alloc& __allocator() const { return __f_.second(); }
Differential Revision: https://reviews.llvm.org/D57355
llvm-svn: 352561
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:
Starting in Clang 8.0 and GCC 8.0, `alignof` and `__alignof` return different values in same cases. Specifically `alignof` and `_Alignof` return the minimum alignment for a type, where as `__alignof` returns the preferred alignment. libc++ currently uses `__alignof` but means to use `alignof`. See llvm.org/PR39713
This patch introduces the macro `_LIBCPP_ALIGNOF` so we can control which spelling gets used.
This patch does not introduce any ABI guard to provide the old behavior with newer compilers. However, if we decide that is needed, this patch makes it trivial to implement.
I think we should commit this change immediately, and decide what we want to do about the ABI afterwards.
Reviewers: ldionne, EricWF
Reviewed By: ldionne, EricWF
Subscribers: jyknight, christof, libcxx-commits
Differential Revision: https://reviews.llvm.org/D54814
llvm-svn: 351289
Patch from Jordan Soyke (jsoyke@google.com)
Reviewed as D55520
This change adds a new internal class, called __value_func, that adds
a minimal subset of value-type semantics to the internal __func interface.
The change is NFC, and is cleanup for the upcoming ABI v2 function implementation (D55045).
llvm-svn: 348778
Summary:
This was voted into C++20 in San Diego. Note that there was a revision
D0318R2 which did include unwrap_reference_t, but we mistakingly voted
P0318R1 into the C++20 Working Draft (which does not include
unwrap_reference_t). This patch implements D0318R2, which is what
we'll end up with in the Working Draft once this mistake has been
fixed.
Reviewers: EricWF, mclow.lists
Subscribers: christof, dexonsmith, libcxx-commits
Differential Revision: https://reviews.llvm.org/D54485
llvm-svn: 348138
Summary:
These deprecation warnings are opt-in: they are only enabled when the
_LIBCXX_DEPRECATION_WARNINGS macro is defined, which is not the case
by default. Note that this is a first step in the right direction, but
I wasn't able to get an exhaustive list of all deprecated components
per standard, so there's certainly stuff that's missing. The list of
components this commit marks as deprecated is:
in C++11:
- auto_ptr, auto_ptr_ref
- binder1st, binder2nd, bind1st(), bind2nd()
- pointer_to_unary_function, pointer_to_binary_function, ptr_fun()
- mem_fun_t, mem_fun1_t, const_mem_fun_t, const_mem_fun1_t, mem_fun()
- mem_fun_ref_t, mem_fun1_ref_t, const_mem_fun_ref_t, const_mem_fun1_ref_t, mem_fun_ref()
in C++14:
- random_shuffle()
in C++17:
- unary_negate, binary_negate, not1(), not2()
<rdar://problem/18168350>
Reviewers: mclow.lists, EricWF
Subscribers: christof, dexonsmith, llvm-commits
Differential Revision: https://reviews.llvm.org/D48912
llvm-svn: 342843
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
Be defensive against a reentrant std::function::operator=(nullptr_t), in case
the held function object has a non-trivial destructor. Destroying the function
object in-place can lead to the destructor being called twice.
Patch by Duncan P. N. Exon Smith. C++03 support by Volodymyr Sapsai.
rdar://problem/32836603
Reviewers: EricWF, mclow.lists
Reviewed By: mclow.lists
Subscribers: cfe-commits, arphaman
Differential Revision: https://reviews.llvm.org/D34331
llvm-svn: 330885
Summary:
Compiling `<functional>` in C++17 or higher mode results in:
```
functional:2500:1: warning: attribute '__visibility__' is ignored, place it after "class" to apply attribute to type declaration [-Wignored-attributes]
_LIBCPP_TYPE_VIS
^
__config:701:46: note: expanded from macro '_LIBCPP_TYPE_VIS'
# define _LIBCPP_TYPE_VIS __attribute__ ((__visibility__("default")))
^
1 warning generated.
```
Fix it by putting the attribute after the `class` keyword.
Reviewers: EricWF, mclow.lists
Reviewed By: EricWF
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D43209
llvm-svn: 325027
This patch fixes llvm.org/PR34298. Previously libc++ incorrectly evaluated
the __invokable trait via the converting constructor `function(Tp)` [with Tp = std::function]
whenever the copy constructor or copy assignment operator
was required. This patch further constrains that constructor to short
circut before evaluating the troublesome SFINAE when `Tp` matches
std::function.
The original patch is from Alex Lorenz.
llvm-svn: 312892
This reverts commit r312890 because the test case fails to compile for
older versions of Clang that reject initializing a const object without
a user defined constructor.
Since this patch should go into 5.0.1, I want to keep it an atomic change,
and will re-commit it with a fixed test case.
llvm-svn: 312891
This patch fixes llvm.org/PR34298. Previously libc++ incorrectly evaluated
the __invokable trait via the converting constructor `function(Tp)` [with Tp = std::function]
whenever the copy constructor or copy assignment operator
was required. This patch further constrains that constructor to short
circut before evaluating the troublesome SFINAE when `Tp` matches
std::function.
The original patch is from Alex Lorenz.
llvm-svn: 312890
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
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
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
Louis Dionne