MSVCRT 12.0 introduces better compatibility for C99. This includes a number of
math routines that were previously undefined. Use the crtversion.h header to
detect the version of MSVCRT being targeted and avoid re-declaring the
variables.
Since copysign has been introduced in MSVCRT, importing the definition via using
makes it difficult to provide overloads (due to minor differences between
throw () and noexcept. Avoid defining the overloads on newer MSVCRT
targets.
llvm-svn: 230867
Summary: Newlib supports ctype differently from other platforms, this patch teaches libc++ about yet another platform that does ctype differently.
Reviewers: jroelofs
Subscribers: cfe-commits, danalbert, EricWF, jvoung, jfb, mclow.lists
Differential Revision: http://reviews.llvm.org/D7888
llvm-svn: 230557
Summary:
Currently parts of the SFINAE on tuples default constructor always gets evaluated even when the default constructor is never called or instantiated. This can cause a hard compile error when a tuple is created with types that do not have a default constructor. Below is a self contained example using a pair like class. This code will not compile but probably should.
```
#include <type_traits>
template <class T>
struct IllFormedDefaultImp {
IllFormedDefaultImp(T x) : value(x) {}
constexpr IllFormedDefaultImp() {}
T value;
};
typedef IllFormedDefaultImp<int &> IllFormedDefault;
template <class T, class U>
struct pair
{
template <bool Dummy = true,
class = typename std::enable_if<
std::is_default_constructible<T>::value
&& std::is_default_constructible<U>::value
&& Dummy>::type
>
constexpr pair() : first(), second() {}
pair(T const & t, U const & u) : first(t), second(u) {}
T first;
U second;
};
int main()
{
int x = 1;
IllFormedDefault v(x);
pair<IllFormedDefault, IllFormedDefault> p(v, v);
}
```
One way to fix this is to use `Dummy` in a more involved way in the constructor SFINAE. The following patch fixes these sorts of hard compile errors for tuple.
Reviewers: mclow.lists, rsmith, K-ballo, EricWF
Reviewed By: EricWF
Subscribers: ldionne, cfe-commits
Differential Revision: http://reviews.llvm.org/D7569
llvm-svn: 230120
Summary:
This patch introduces some black magic to detect const and volatile qualified function types such as `void () const`.
The patch works in the following way:
We first rule out any type that satisfies on of the following. These restrictions are important so that the test below works properly.
* `is_class<_Tp>::value`
* `is_union<_Tp>::value`
* `is_void<_Tp>::value`
* `is_reference<_Tp>::value`
* `__is_nullptr_t<_Tp>::value`
If none of the above is true we perform overload resolution on `__source<_Tp>(0)` to determine the return type.
* If `_Tp&` is well-formed we select `_Tp& __source(int)`. `_Tp&` is only ill formed for cv void types and cv/ref qualified function types.
* Otherwise we select `__dummy_type __source(...)`. Since we know `_Tp` cannot be void then it must be a function type.
let `R` be the returned from `__source<_Tp>(0)`.
We perform overload resolution on `__test<_Tp>(R)`.
* If `R` is `__dummy_type` we call `true_type __test(__dummy_type)`.
* if `R` is `_Tp&` and `_Tp&` decays to `_Tp*` we call `true_type __test(_Tp*)`. Only references to function types decay to a pointer of the same type.
* In all other cases we call `false_type __test(...)`.
`__source<_Tp>(0)` will try and form `_Tp&` in the return type. if `_Tp&` is not well formed the return type of `__source<_Tp>(0)` will be dummy type. `_Tp&` is only ill-formed for cv/ref qualified function types (and void which is dealt with elsewhere).
This fixes PR20084 - http://llvm.org/bugs/show_bug.cgi?id=20084
Reviewers: rsmith, K-ballo, mclow.lists
Reviewed By: mclow.lists
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D7573
llvm-svn: 229696
Summary:
This patch is pretty simple. It just adds the _v traits from <ratio>.
The draft can be found here.
Reviewers: jroelofs, K-ballo, mclow.lists
Reviewed By: mclow.lists
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D7351
llvm-svn: 229509
Visual Studio's SAL extension uses a macro named __deallocate. This macro is
used pervasively, and gets included through various different ways. This
conflicts with the similarly named interfaces in libc++. Introduce a undef
header similar to __undef_min_max to handle this. This fixes a number of errors
due to the macro replacing the function name.
llvm-svn: 229162
cctype uses ctype functions such as isblank. However, when building against
msvcrt, this is provided by the support header. Include the support header if
building for Windows to ensure that the definition is properly visible.
llvm-svn: 229161
Summary:
The bug can be found here: http://llvm.org/bugs/show_bug.cgi?id=22468
`__invoke_void_return_wrapper` is needed to properly handle calling a function that returns a value but where the std::function return type is void. Without this '-Wsystem-headers' will cause `function::operator()(...)` to not compile.
Reviewers: eugenis, K-ballo, mclow.lists
Reviewed By: mclow.lists
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D7444
llvm-svn: 228705
Summary:
The requirement on the `Size` type passed to *_n algorithms is that it is convertible to an integral type. This means we can't use a variable of type `Size` directly. Instead we need to convert it to an integral type first. The problem is finding out what integral type to convert it to. `__convert_to_integral` figures out what integral type to convert it to and performs the conversion, It also promotes the resulting integral type so that it is at least as big as an integer. `__convert_to_integral` also has a special case for converting enums. This should only work on non-scoped enumerations because it does not apply an explicit conversion from the enum to its underlying type.
Reviewers: chandlerc, mclow.lists
Reviewed By: mclow.lists
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D7449
llvm-svn: 228704
Add a new _LIBCPP_UNUSED define in __config, which can be used to
indicate explicitly unused items, and apply it to the __imp__ field of
__libcpp_refstring.
Somebody who knows about Microsoft C++ and IBM C++ should fill in the
unused attribute syntax appropriate for those compilers, if there is
any.
Differential Revision: http://reviews.llvm.org/D6836
llvm-svn: 228281
he following snippet doesn't build when using gcc and libc++:
#include <string>
void f(const std::string& s) { s.begin(); }
#include <vector>
void AppendTo(const std::vector<char>& v) { v.begin(); }
The problem is that __wrap_iter has a private constructor. It lists vector<>
and basic_string<> as friends, but gcc seems to ignore this for vector<> for
some reason. Declaring vector before the friend declaration in __wrap_iter is
enough to work around this problem, so do that. With this patch, I'm able to
build chromium/android with libc++. Without it, two translation units fail to
build. (iosfwd already provides a forward declaration of basic_string.)
As far as I can tell, this is due to a gcc bug, which I filed as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64816.
Fixes PR22355.
http://reviews.llvm.org/D7201
llvm-svn: 227226
Summary:
Excerpt from [atomics.types.operations.req]/21:
> When only one memory_order argument is supplied, the value of
> success is order, and the value of failure is order except that a
> value of memory_order_acq_rel shall be replaced by the value
> memory_order_acquire and a value of memory_order_release shall be
> replaced by the value memory_order_relaxed.
Clean up some copy pasta while I'm here (someone added a return
statement to a void function).
Reviewers: EricWF, jroelofs, mclow.lists
Reviewed By: mclow.lists
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D6632
llvm-svn: 225280
The SFINAE on the function __mu(Fn, Args...) that evaluates nested bind
expressions always tries to deduce the return type for Fn(Args...) even when Fn
is not a nested bind expression. This can cause hard compile errors when the
instantation of Fn(Args...) is ill-formed. This patch prevents the instantation
of __invoke_of<Fn, Args...> unless Fn is actually a bind expression.
Bug reportand patch from Michel Morin.
http://llvm.org/bugs/show_bug.cgi?id=22003
llvm-svn: 224753
It might be implicitly included by <pthread.h> (and that's why it worked
so far), but it's not guaranteed (for example, this is not the case with
newlib).
llvm-svn: 223661
Summary:
The NaCl sandbox doesn't allow opening files under /dev, but it offers an API which provides the same capabilities. This is the same random device emulation that nacl_io performs for POSIX support, but nacl_io is an optional library so libc++ can't assume that device emulation will be performed. Note that NaCl only supports /dev/urandom, not /dev/random.
This patch also cleans up some of the preprocessor #endif, and fixes the test for Win32 (it accepts any token, and would therefore never throw regardless of the token provided).
Test Plan: ninja check-libcxx
Reviewers: dschuff, mclow.lists, danalbert
Subscribers: jfb, cfe-commits
Differential Revision: http://reviews.llvm.org/D6442
llvm-svn: 223068
Summary:
The size of the vector is being increased by `__n` during the call to `__move_range` and not by 1.
This fixes a test failure in `containers/sequences/vector/vector.modifiers/insert_iter_size_value.pass.cpp` when using ASAN.
Reviewers: danalbert, kcc, mclow.lists
Reviewed By: mclow.lists
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D6264
llvm-svn: 222014
Summary:
http://llvm.org/bugs/show_bug.cgi?id=18345
Tuple's constructor and assignment operators for "tuple-like" types evaluates __make_tuple_types unnecessarily. In the case of a large array this can blow the template instantiation depth.
Ex:
```
#include <array>
#include <tuple>
#include <memory>
typedef std::array<int, 1256> array_t;
typedef std::tuple<array_t> tuple_t;
int main() {
array_t a;
tuple_t t(a); // broken
t = a; // broken
// make_shared uses tuple behind the scenes. This bug breaks this code.
std::make_shared<array_t>(a);
}
```
To prevent this from happening we delay the instantiation of `__make_tuple_types` until after we perform the length check. Currently `__make_tuple_types` is instantiated at the same time that the length check .
Test Plan: Two tests have been added. One for the "tuple-like" constructors and another for the "tuple-like" assignment operator.
Reviewers: mclow.lists, EricWF
Reviewed By: EricWF
Subscribers: K-ballo, cfe-commits
Differential Revision: http://reviews.llvm.org/D4467
llvm-svn: 220769
Summary: This fixes ODR violations in C++03 mode in test/localization/locale.stdcvt. The special case for linux was introduced in 2010 before clang always defined __char16_t and __char32_t.
Reviewers: mclow.lists, danalbert, jroelofs, EricWF
Reviewed By: EricWF
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D5930
llvm-svn: 220716
The comma operators in the test iterators give better error messages when they
are deleted as opposed to not defined. Delete these functions when possible.
llvm-svn: 220715
Summary:
An evil user might overload operator comma. Use a void cast to make sure any user overload is not selected.
Modify all the test iterators to define operator comma.
Reviewers: danalbert, mclow.lists
Reviewed By: mclow.lists
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D5929
llvm-svn: 220706
This essentially re-does r194825 and makes it possible to run clang
with libc++ without having to install it, even if you don't have any
version of libc++ installed in /usr/.
This behaviour broke in r210577/r211629, which fixed pr18681.
llvm-svn: 220489
Summary:
This patch is very closely related to D4859. Please see http://reviews.llvm.org/D4859 for more information.
This patch adds support for "fancy" pointers and allocators to promise and packaged_task. The changes made to support this are exactly the same as in D4859.
Test Plan: "fancy" pointer tests were added to each constructor affected by the change.
Reviewers: danalbert, mclow.lists
Reviewed By: mclow.lists
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D4862
llvm-svn: 220471
Summary:
This patch add support for "fancy pointers/allocators" as well as fixing support for shared_pointer and "minimal" allocators.
Fancy pointers are class types that meet the NullablePointer requirements. In our case they are created by fancy allocators. `support/min_allocator.h` is an archetype for these types.
There are three types of changes made in this patch:
1. `_Alloc::template rebind<T>::other` -> `__allocator_traits_rebind<_Alloc, T>::type`. This change was made because allocators don't need a rebind template. `__allocator_traits_rebind` is used instead of `allocator_traits::rebind` because use of `allocator_traits::rebind` requires a workaround for when template aliases are unavailable.
2. `a.deallocate(this, 1)` -> `a.deallocate(pointer_traits<self>::pointer_to(*this), 1)`. This change change is made because fancy pointers aren't always constructible from raw pointers.
3. `p.get()` -> `addressof(*p.get())`. Fancy pointers aren't actually a pointer. When we need a "real" pointer we take the address of dereferencing the fancy pointer. This should give us the actual raw pointer.
Test Plan: Tests were added using `support/min_allocator.h` to each affected shared_ptr overload and creation function. These tests can only be executed in C++11 or greater since min_allocator is only available then. A extra test was added for the non-variadic versions of allocate_shared.
Reviewers: danalbert, mclow.lists
Reviewed By: mclow.lists
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D4859
llvm-svn: 220469
Delay instantiation of `__numeric_type` within <cmath>,
don't instantiate it when the `is_arithmetic` conditions do not hold as it causes
errors with user-defined types with ambiguous conversions. Fixes PR21083.
llvm-svn: 219998
With clang, the header atomic requires __has_feature(cxx_atomic), which is only
true in c++11 mode. Because of this, when using modules in c++98 with libc++
compilation of the std module would fail without this change, PR21002.
(With gcc, only gcc4.7+ is needed, no c++11. But gcc doesn't have modules yet,
and the module.modulemap language can't express things like "this is only
required if the compiler is clang". If gcc gets module support, we'd probably
have a module.modulemap file for each compiler that libc++ supports?)
llvm-svn: 218372
GCC 4.9 fails to inline these functions at -O1 because they are used
indirectly. Declare them as inline instead of always_inline. Discussion
in GCC bugreport: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63220
llvm-svn: 217961
Saleem Abdulrasool