Summary:
Hi all,
This patch is a successor to D11963. However it has changed dramatically and I felt it would be best to start a new review thread.
Please read the design documentation added in this patch for a description of how it works.
Reviewers: mclow.lists, danalbert, jroelofs, EricWF
Subscribers: vkalintiris, rnk, ed, espositofulvio, asl, eugenis, cfe-commits
Differential Revision: http://reviews.llvm.org/D13407
llvm-svn: 250235
Also fix the overload set for the five functions whose signatures change in the
case where we can fix it. This is already covered by existing tests for the
affected systems.
llvm-svn: 249929
There are a bunch of macros (__need_size_t etc) that request just one piece of
<stddef.h>; if any one of these is defined, we just directly include the
underlying header.
Note that <stddef.h> provides a ::nullptr_t. We don't want that available to
includers of <cstddef>, so instead of following the usual pattern where <cfoo>
includes <foo.h> then pulls things from :: into std:: with using-declarations,
we implement <stddef.h> and <cstddef> separately; both include <__nullptr> for
the definition of std::nullptr_t.
llvm-svn: 249761
The C standard requires that these be provided as functions even if they're
also provided as macros, and a strict reading of the C++ standard library rules
suggests that (for instance) &::isdigit == &::std::isdigit, so these wrappers
are technically non-conforming.
llvm-svn: 249475
Summary:
Hi Marshall,
Could you please test this patch and see if you run into the same linker errors we talked about?
I can't reproduce on linux or OS X.
Hopefully you can't find any problems and we can fix the C++03 bot.
Reviewers: mclow.lists
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D13337
llvm-svn: 249192
Summary:
This patch properly constrains the converting assignment operator in C++03. It also fixes a bug where std::forward was given the wrong type.
The following two tests begin passing in C++03:
* `unique_ptr.single.asgn/move_convert.pass.cpp`
* `unique_ptr.single.asgn/move_convert13.fail.cpp`
Reviewers: mclow.lists
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D12173
llvm-svn: 246272
Summary:
This patch optimizes basic_string::compare to use strcmp when the default char_traits has been given.
See PR19900 for more information. https://llvm.org/bugs/show_bug.cgi?id=19900
Reviewers: mclow.lists
Subscribers: bkramer, cfe-commits
Differential Revision: http://reviews.llvm.org/D12355
llvm-svn: 246266
Summary:
This patch rewrites the C++03 `__invoke` and related meta-programming. There are a number of major changes.
`__invoke` in C++03 now has a fallback overload for when the invoke expression is ill-formed (similar to C++11). This means that the `__invoke_return` traits will return `__nat` when `__invoke(...)` is ill formed. This would previously cause a compile error.
Bullets 1-4 of `__invoke` have been rewritten. In the old version `__invoke` had 32 overloads for bullets 1 and 2,
one for each possible cv-qualified function signature with arities 0-3. 64 overloads would be needed to support member functions
with varargs. Currently these overloads were fundamentally broken. An example overload looked like:
```
template <class Rp, class Tp, class T1, class A0>
Rp __invoke(Rp (Tp::*pm)(A0) const, T1&, A0&)
```
Because `A0` appeared in two different deducible contexts it would have to deduce to be an exact match or the overload
would be rejected. This is made even worse because `A0` appears without a reference qualifier in the member function signature
and with a reference qualifier as an `__invoke` parameter. This means that only member functions that took all
of their arguments by value could be matched.
One possible fix would be to make the second occurrence of `A0` appear in a non-deducible context. This way
any type convertible to `A0` could be passed as the first parameter. The benefit of this approach is that the
signature of the member function enforces the arity and types taken by the `__invoke` signature it generates. However
nothing in the `INVOKE` specification requires this behavior.
My solution is to use a `__invoke_enable_if<PM_Type, Tp>` metafunction to selectively enable the `__invoke` overloads for bullets 1, 2, 3 and 4. It uses `__member_function_traits` to inspect and extract the return type and class type of the pointer to member. Using `__member_function_traits` to inspect `PM_Type` also allows us to reduce the number of `__invoke` overloads from 32 to 8 and add
varargs support at the same time.
Because `__invoke_enable_if` knows the exact return type of `__invoke` for bullets 1-4 we no longer need to use `decltype(__invoke(...))` to
compute the return type in the `__invoke_return*` traits. This will reduce the problems caused by `#define decltype(X) __typeof__(X)` in C++03.
Tests for this change have already been committed. All tests in `test/std/utilities/function.objects` now pass in C++03, previously there were 20 failures.
Reviewers: K-ballo, howard.hinnant, mclow.lists
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D11553
llvm-svn: 246068
Currently we need an #ifdef branch every time we use pointer traits to rebind a pointer because
it is done differently in C++11 and C++03. This patch introduces the __rebind_pointer utility to
clean this up.
Also add a test that list and it's iterators can be instantiated with incomplete element types.
llvm-svn: 245806
Currently we need an #ifdef branch every time we use pointer traits to rebind a pointer because
it is done differently in C++11 and C++03. This patch introduces the __rebind_pointer utility to
clean this up.
llvm-svn: 245802
Summary: Currently you can't install libc++ from within the LLVM tree without installing all of LLVM. This patch adds an install rule for libc++.
Reviewers: mclow.lists, danalbert, jroelofs, EricWF
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D11697
llvm-svn: 245470
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
Summary:
Throughout the libc++ headers, there are a few instances where
_VSTD::move() is used to return a local variable. Howard commented in
r189039 that these were there "for non-obvious reasons such as to help
things limp along in C++03 language mode".
However, when compiling these headers with warnings on, and in C++11 or
higher mode (like we do in FreeBSD), they cause the following complaints
about pessimizing moves:
In file included from tests.cpp:26:
In file included from tests.hpp:29:
/usr/include/c++/v1/map:1368:12: error: moving a local object in a return statement prevents copy elision [-Werror,-Wpessimizing-move]
return _VSTD::move(__h); // explicitly moved for C++03
^
/usr/include/c++/v1/__config:368:15: note: expanded from macro '_VSTD'
#define _VSTD std::_LIBCPP_NAMESPACE
^
Attempt to fix this by adding a _LIBCPP_EXPLICIT_MOVE() macro to
__config, which gets defined to _VSTD::move for pre-C++11, and to
nothing for C++11 and later.
I am not completely satisfied with the macro name (I also considered
_LIBCPP_COMPAT_MOVE and some other variants), so suggestions are
welcome. :)
Reviewers: mclow.lists, howard.hinnant, EricWF
Subscribers: arthur.j.odwyer, cfe-commits
Differential Revision: http://reviews.llvm.org/D11394
llvm-svn: 245421
Summary:
This patch fixes __not_null's detection of nullptr by breaking it down into 4 cases.
1. `__not_null(Tp const&)`: Default case. Tp is not null.
2. `__not_null(Tp* __ptr);` Case for pointers to functions.
3. `__not_null(_Ret _Class::* __ptr);` Case for pointers to members.
4. `__not_null(function<Tp> const&);`: Cases for other std::functions.
Reviewers: mclow.lists
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D11111
llvm-svn: 245335
Summary:
See https://llvm.org/bugs/show_bug.cgi?id=22606 for more discussion.
Most of the changes in this patch are file reorganization to help ensure assumptions about how __thread_specific_pointer is used hold. The assumptions are:
* `__thread_specific_ptr<Tp>` is only created with a `__thread_struct` pointer.
* `__thread_specific_ptr<Tp>` can only be constructed inside the `__thread_local_data()` function.
I'll remove the comments before committing. They are there for clarity during review.
Reviewers: earthdok, mclow.lists
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D8802
llvm-svn: 245334
Summary:
Normally people won't see warnings in libc++ headers, but if they compile with "-Wsystem-headers -Wnon-virtual-dtor" they will likely see issues in <locale>.
In the libc++ implementation `time_get' has a private base class, `__time_get_c_storage`, with virtual methods but a non-virtual destructor.
`time_get` itself can safely be used as a polymorphic base class because it inherits a virtual destructor from `locale::facet`. To placate the compiler we change `__time_get_c_storage`'s destructor from public to protected, ensuring that it will never be deleted polymorphically.
Reviewers: mclow.lists
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D11670
llvm-svn: 245333
The key changes in this patch are:
1. Remove the zero-argument overload in mem_fn. A member function must always
be invoked with at least one argument, the class instance. The zero-argument
operator()() in mem_fn would cause mem_fn to fail to compile when because
the call to '__invoke(pm)' is not well formed.
2. Prevent evaluation of '__apply_cv<Tp, Ret>' when 'Ret' is a function type.
'Ret' is a function type whenever 'Ret Tp::*' is a pointer to member function.
Attempting to add cv and ref qualifiers to a function type can cause a hard
compile error.
3. Remove the dummy overload __invoke(Rp Tp::*). It was present to help work
around #1. It will be replaced with a different '__invoke' overload that
represents a bad call to invoke.
After applying this patch the test func.wrap.func.inv/invoke.pass.cpp now
passes.
llvm-svn: 243370
This patch does a couple of things to get __invoke working for free-functions
and call objects.
1. Turn all uses of declval<Tp>() into declval<Tp&>(). The C++03 __invoke only
supports lvalues but it will be used when the compiler supports rvalue
references but not variadic templates. This change makes sure we don't
generate an rvalue.
2. Call objects for bullet 5 are now passed by reference and not value. Copying
the functor is incorrect. It will fail to compile for non-copyable functors
and it will discard cv-qualifiers on the call object, possibly leading to the
wrong function being called. I suspect that the reason the call object
was originally taken by value was to support temporary call objects.
However __invoke is only used internally and it is never given a temporary.
llvm-svn: 243368
The implementation of mem_fn doesn't actually require any C++11 support.
For some reason there were 17 overloads for mem_fn in C++03 when only one
is needed. This patch removes the extra overloads and uses the same implementation
of mem_fn in C++03 and C++11.
__mem_fn does require variadics to implement the call operator. Instead of
having two entirely different implementations of the __mem_fn struct, this patch
uses the same __mem_fn struct but provides different call operators when
variadics are not available.
The only thing left in <__functional_03> is the C++03 implementation of
std::function.
llvm-svn: 242959
This patch removes a large amount of duplicate code found in both
<__functional_base> and <__functional_base_03>. The only code that remains
in <__functional_base_03> is the C++03 implementation of __invoke and
__invoke_return.
llvm-svn: 242951
<__functional_03> provides the C++03 definitions for std::memfun and
std::function. However the interaction between <functional> and <__functional_03>
is ugly and duplicates code needlessly. This patch cleans up how the two
headers work together.
The major changes are:
- Provide placeholders, is_bind_expression and is_placeholder in <functional>
for both C++03 and C++11.
- Provide bad_function_call, function fwd decl,
__maybe_derive_from_unary_function and __maybe_derive_from_binary_function
in <functional> for both C++03 and C++11.
- Move the <__functional_03> include to the bottom of <functional>. This makes
it easier to see how <__functional_03> interacts with <functional>
- Remove a commented out implementation of bind in C++03. It's never going
to get implemented.
- Mark almost all std::bind tests as unsupported in C++03. std::is_placeholder
works in C++03 and C++11. std::is_bind_expression is provided in C++03 but
always returns false.
llvm-svn: 242870
Although CMake adds warning flags, they are ignored in the libc++ headers
because the headers '#pragma system header' themselves.
This patch disables the system header pragma when building libc++ and fixes
the warnings that arose.
The warnings fixed were:
1. <memory> - anonymous structs are a GNU extension
2. <functional> - anonymous structs are a GNU extension.
3. <__hash_table> - Embedded preprocessor directives have undefined behavior.
4. <string> - Definition is missing noexcept from declaration.
5. <__std_stream> - Unused variable.
llvm-svn: 242623
Summary: This patch adds proper guards to the is_destructible tests depending on the standard version so that they pass in c++03.
Reviewers: mclow.lists, EricWF
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D10047
llvm-svn: 242612
Summary:
In some places in libc++ we need to use the `__atomic_*` builtins. This patch adds a header that provides access to those builtins in a uniform way from within the dylib source.
If the compiler building the dylib does not support these builtins then a warning is issued.
Only relaxed loads are needed within the headers. A singe function to do these relaxed loads has been added to `<memory>`.
This patch applies the new atomic builtins to `__shared_count` and `call_once`.
Reviewers: mclow.lists
Subscribers: majnemer, jroelofs, cfe-commits
Differential Revision: http://reviews.llvm.org/D10406
llvm-svn: 241532
The __cloc() function is only present in case the environment does not
provide a way to refer to the C locale using a compile-time constant
expression. _LIBCPP_GET_C_LOCALE seems to be defined unconditionally.
This improves compilation of the locale code on CloudABI.
Differential Revision: http://reviews.llvm.org/D10690
Reviewed by: jroelofs
llvm-svn: 241454
One of the aspects of CloudABI is that it aims to help you write code
that is thread-safe out of the box. This is very important if you want
to write libraries that are easy to reuse. For CloudABI we decided to
not provide the thread-unsafe functions. So far this is working out
pretty well, as thread-unsafety issues are detected really early on.
The following patch adds a knob to libc++,
_LIBCPP_HAS_NO_THREAD_UNSAFE_C_FUNCTIONS, that can be set to disable
thread-unsafe functions that can easily be avoided in practice. The
following functions are not thread-safe:
- <clocale>: locale handles should be preferred over setlocale().
- <cstdlib>: mbrlen(), mbrtowc() and wcrtomb() should be preferred over
their non-restartable counterparts.
- <ctime>: asctime(), ctime(), gmtime() and localtime() are not
thread-safe. The first two are also deprecated by POSIX.
Differential Revision: http://reviews.llvm.org/D8703
Reviewed by: marshall
llvm-svn: 240527
Richard Smith