Summary:
This patch adds the `<experimental/tuple>` header (almost) as specified in the latest draft of the library fundamentals TS.
The main changes in this patch are:
1. Added variable template `tuple_size_v`
2. Added function `apply(Func &&, Tuple &&)`.
3. Changed `__invoke` to be `_LIBCPP_CONSTEXPR_AFTER_CXX11`.
The `apply(...)` implementation uses `__invoke` to invoke the given function. `__invoke` already provides the required functionality. Using `__invoke` also allows `apply` to be used on pointers to member function/objects as an extension. In order to facilitate this `__invoke` has to be marked `constexpr`.
Test Plan:
Each new feature was tested.
The test cases for `tuple_size_v` are as follows:
1. tuple_size_v.pass.cpp
- Check `tuple_size_v` on cv qualified tuples, pairs and arrays.
2. tuple_size_v.fail.cpp
- Test on reference type.
3. tuple_size_v_2.fail.cpp
- Test on non-tuple
4. tuple_size_v_3.fail.cpp
- Test on pointer type.
The test cases for tuple.apply are as follows:
1. arg_type.pass.cpp
- Ensure that ref/pointer/cv qualified types are properly passed.
2. constexpr_types.pass.cpp
- Ensure constexpr evaluation of apply is possible for `tuple` and `pair`.
3. extended_types.pass.cpp
- Test apply on function types permitted by extension.
4. large_arity.pass.cpp
- Test that apply can evaluated on tuples and arrays with large sizes.
5. ref_qualifiers.pass.cpp
- Test that apply respects ref qualified functions.
6. return_type.pass.cpp
- Test that apply returns the proper type.
7. types.pass.cpp
- Test apply on function types as required by LFTS.
Reviewers: mclow.lists
Reviewed By: mclow.lists
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D4512
llvm-svn: 232515
Summary:
There is no reason to guard `tuple_size`, `tuple_element` and `get<I>(...)` for pair and array inside of `<__tuple>` so that they are only available when we have variadic templates.
This requires there be redundant declarations and definitions. It also makes it easy to get things wrong.
For example the following code should compile (and does in c++11).
```
#define _LIBCPP_HAS_NO_VARIADICS
#include <array>
int main()
{
static_assert((std::tuple_size<std::array<int, 10> volatile>::value == 10), "");
}
```
This patch lifts the non-variadic parts of `tuple_size`, `tuple_types`, and `get<I>(...)` to the top of `<__tuple>` where they don't require variadic templates. This patch also removes `<__tuple_03>` because there is no longer a need for it.
Reviewers: danalbert, K-ballo, mclow.lists
Reviewed By: mclow.lists
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D7774
llvm-svn: 232492
According to POSIX, *abs() and *div() are allowed to be macros (in
addition to being functions). Make sure we undefine these, so that
std::*abs() and std::*div() work as expected.
llvm-svn: 232379
Systems like FreeBSD's Capsicum and Nuxi CloudABI apply the concept of
capability-based security on the way processes can interact with the
filesystem API. It is no longer possible to interact with the VFS
through calls like open(), unlink(), rename(), etc. Instead, processes
are only allowed to interact with files and directories to which they
have been granted access. The *at() functions can be used for this
purpose.
This change adds a new config switch called
_LIBCPP_HAS_NO_GLOBAL_FILESYSTEM_NAMESPACE. If set, all functionality
that requires the global filesystem namespace will be disabled. More
concretely:
- fstream's open() function will be removed.
- cstdio will no longer pull in fopen(), rename(), etc.
- The test suite's get_temp_file_name() will be removed. This will cause
all tests that use the global filesystem namespace to break, but will
at least make all the other tests run (as get_temp_file_name will not
build anyway).
It is important to mention that this change will make fstream rather
useless on those systems for now. Still, I'd rather not have fstream
disabled entirely, as it is of course possible to come up with an
extension for fstream that would allow access to local filesystem
namespaces (e.g., by adding an openat() member function).
Differential revision: http://reviews.llvm.org/D8194
Reviewed by: jroelofs (thanks!)
llvm-svn: 232049
This basically reverts the revert in r216508, and fixes a few more cases while
I'm at it. Reading my commit message on that commit again, I think it's bupkis.
http://reviews.llvm.org/D8237
llvm-svn: 231940
On a new platform that I am working on
(https://github.com/NuxiNL/cloudlibc) I am not implementing the
cat{open,close,gets}() API, just like Android, Newlib, etc.
Instead of adding yet another operating system name to the #ifs,
introduce _LIBCPP_HAS_CATOPEN in include/__config. Also adjust the code
to only pull in nl_types.h when _LIBCPP_HAS_CATOPEN is set. We only
needed this header for the cat*() API.
Differential Revision: http://reviews.llvm.org/D8163
Reviewed by: marshall
llvm-svn: 231937
Before I discovered that NetBSD provides a permanent handle to the C
locale called LC_C_LOCALE, I also added support for this to CloudABI
under the name LC_POSIX_LOCALE. I've renamed it to LC_C_LOCALE to
improve compatibility.
llvm-svn: 231780
CloudABI provides the _l() functions that are part of POSIX.1-2008, but
also the extensions that are available on systems like OS X and *BSD
(scanf_l, printf_l, etc).
llvm-svn: 231777
There are a couple of places where libc++ prints log/error messages to
stdout on its own. This may of course interfere with the output
generated with applications. Log/error messages should be directed to
stderr instead.
Differential Revision: http://reviews.llvm.org/D8135
Reviewed by: marshall
llvm-svn: 231767
Nuxi CloudABI (https://github.com/NuxiNL/cloudlibc) does not allow
processes to access the global filesystem namespace. This breaks
random_device, as it attempts to use /dev/{u,}random. This change adds
support for arc4random(), which is present on CloudABI.
In my opinion it would also make sense to use arc4random() on other
operating systems, such as *BSD and Mac OS X, but I'd rather leave that
to the maintainers of the respective platforms. Switching to
arc4random() does change the ABI.
This change also attempts to make some cleanups to the code. It adds a
single #define for every random interface, instead of testing against
operating systems explicitly.
As discussed, also validate the token argument to be equal to
"/dev/urandom" on all systems that only provide pseudo-random numbers.
This should cause little to no breakage, as "/dev/urandom" is also the
default argument value.
Reviewed by: jfb
Differential Revision: http://reviews.llvm.org/D8134
llvm-svn: 231764
Summary: Fix suggested by @mclow.lists on D8109. Store the size of the un-poisoned vector upon construction instead of calculating it later.
Reviewers: titus, mclow.lists, kcc, EricWF
Reviewed By: EricWF
Subscribers: mclow.lists, cfe-commits
Differential Revision: http://reviews.llvm.org/D8172
llvm-svn: 231729
The _Pp typedef in __tree<_Tp, _Compare, _Allocator>::__count_multi()
isn't used anywhere, so adding _LIBCPP_UNUSED is unecessary.
Differential Revision: http://reviews.llvm.org/D8140
llvm-svn: 231705
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
If you're crazy enough to want this sort of thing, then add
-D_LIBCPP_HAS_NO_THREADS to your CXXFLAGS and
--param=additiona_features=libcpp-has-no-threads to your lit commnad line.
http://reviews.llvm.org/D3969
llvm-svn: 217271
Turning off explicit template instantiation leads to a pretty
significant build time and code size cost. We're better off dealing
with ABI incompatibility issues that come up in a less heavy handed
way.
This reverts commit r189610.
llvm-svn: 215740
This patch just adds the required return statements to slice_array::operator=
and mask_array::operator=.
Tests were added to check that the return value is the same as the object assigned
to.
llvm-svn: 215414
Things done in this patch:
1. Make __debug include __config since it uses macros from it.
2. The current method of defining _LIBCPP_ASSERT is prone to redefinitions. Move
the null _LIBCPP_ASSERT definition into the __debug header to prevent this.
3. Remove external <__debug> include gaurds. <__debug> guards almost all of its
contents internally. There is no reason to be doing it externally.
This patch should not change any functionality.
llvm-svn: 215332
gcc 4.7 and above has atomic built-ins which slightly different APIs
from those provided by clang. Add proxy functions that wrap the gcc
built-ins to produce a symbol that is API equivalent to the clang
built-ins. This allows libc++'s atomic library to be used with gcc-4.7
and newer.
Patch contributed by Albert Wong.
llvm-svn: 215305
Summary: This patch moves the SFINAE for __is_destructor_welformed out of the function template parameters. type_traits must compile in c++03 mode since it is included in c++03 headers.
Test Plan: No tests have been added.
Reviewers: danalbert, mclow.lists
Reviewed By: danalbert
Subscribers: K-ballo, cfe-commits
Differential Revision: http://reviews.llvm.org/D4735
llvm-svn: 214422
__get_classname() and __bracket_expression were assuming that
char_class_type was ctype_base::mask rather than using
regex_traits<_CharT>::char_class_type.
This change allows char_class_type to be defined to something other than
ctype_base::mask so that the implementation will still work for
platforms with an 8-bit ctype mask (such as Android and OpenBSD).
llvm-svn: 214201
Summary: The polymorphic allocator implementation would greatly benefit by defining virtual functions in the dynlib instead of inline. In order to do that some types are going to have to be available outside of c++1y. This is the first step.
Reviewers: mclow.lists, EricWF
Reviewed By: EricWF
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D4554
llvm-svn: 213889
std::make_heap is currently implemented by iteratively applying a
siftup-type algorithm. Since sift-up is O(ln n), this gives
std::make_heap a worst case time complexity of O(n ln n).
The C++ standard mandates that std::make_heap make no more than O(3n)
comparisons, this makes our std::make_heap out of spec.
Fix this by introducing an implementation of __sift_down and switch
std::make_heap to create the heap using it.
This gives std::make_heap linear time complexity in the worst case.
This fixes PR20161.
llvm-svn: 213615
Summary:
This patch adds the `<experimental/utility>` header as specified in the latest draft of the library fundamentals TS.
`<experimental/utility>` only contains `class erased_type`.
This patch also updates the documentation to list the `erased_type` class as "initial implementation complete".
Test Plan:
Three test cases where added:
1. Test that `_LIBCPP_VERSION` is defined.
2. Test that `<utility>` has been included.
3. Test that `erased_type` is in the correct namespace and is constexpr default constructible.
Reviewers: mclow.lists
Reviewed By: mclow.lists
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D4510
llvm-svn: 213226
Mark the base classes for time_get_byname and time_get as _LIBCPP_TYPE_VIS_ONLY
rather than _LIBCPP_TYPE_VIS. These base classes are templated types and cannot
be stored with export dll storage.
Fixes compilation with _LIBCPP_DLL for Windows when the time_get and
time_get_byname classes are used.
llvm-svn: 213116
libc++ currently relies on undefined initialization order of global
initializers when using gcc:
1. __start_std_streams in iostream.cpp calls locale:🆔:_init, which assigns
an id to each locale::facet in an initializer
2. Every facet has a static locale::id id, whose constructor sets the facet's
id to 0
If 2 runs after 1, it clobbers the facet's assigned consecutive id, causing
exceptions to be thrown when e.g. running code like "cout << endl".
To fix this, let _LIBCPP_CONSTEXPR evaluate to "constexpr" instead of nothing
with gcc. locale::id's constructor is marked _LIBCPP_CONSTEXPR, which ensures
that it won't get an initializer that could potentially run after the
iostream.cpp initializer. (This remains broken when building with msvc.)
Also switch constexpr-specific code in bitset to use __SIZEOF_SIZE_T__ instead
of __SIZE_WIDTH__, because gcc doesn't define the latter.
Pair-programmed/debugged with Dana Jansens.
llvm-svn: 210188
(clang doesn't complain about this, but gcc does. This is necessary for a
follow-up patch that will enable _LIBCPP_CONSTEXPR for gcc.)
llvm-svn: 209888
r207606 changed the __need_foo macros to behave like they do with gcc: If they
are set, _only_ the __need_foo stuff gets defined. As a consequence, cstddef
no longer defined "offsetof". It looks like the __need_foo defines aren't
needed anymore, so just remove them.
Fixes PR19723.
llvm-svn: 208942
compatibility to libstdc++. Move the implementation into a header for
easier sharing with libc++abi. Merge a number of improvements from that
version. Provide a POD definition for <stdexcept>'s public use to avoid
cast dances. Discussed with Marshall Clow.
llvm-svn: 207695
libc++ will not call address_sanitizer to detect addressing errors in the
standard library containers. This is a negative macro to enable users to
disable the libc++ checks even if they are compiling with address sanitizer
enabled by defining this macro.
At the present time, there is no code in libc++ that looks at this macro.
That will come soon. This is just infrastructure.
llvm-svn: 206184
It's identical to name() these days. (At one point it avoided masking
of the RTTI uniqueness bit because ARM64 ignored it architecturally,
but no longer).
llvm-svn: 205518
ARM64 generates RTTI with hidden visibility, which means that typeinfo
must be compared char-by-char since it's not guaranteed to be uniqued
across the whole program.
llvm-svn: 205139
This is as straightforward as it sounds, a renamed from shared_mutex to
shared_timed_mutex.
Note that libcxx .dylib and .so files built with c++14 support need to
be rebuilt.
llvm-svn: 204078
Instead, define explicit specializations for the basic types listed in
the SGI documentation. This solves two problems:
1) Helps avoid silent ODR violations caused by the absence of a
user-supplied __gnu_cxx::hash specialization in cases where a std::hash
specialization exists (e.g. for std::string).
2) __gnu_cxx::hash semantics are slightly different to those of
std::hash (for example, the former may dereference a pointer argument)
so it is inappropriate for __gnu_cxx::hash to receive std::hash
specializations by default.
Differential Revision: http://llvm-reviews.chandlerc.com/D2747
llvm-svn: 203070
Error 1 error C2681: 'add_rvalue_reference<_Tp*>::type' : invalid expression
type for dynamic_cast c:\libcxx\include\type_traits
This is one more step getting libcxx compile under Visual C++. The patch is
#if defined(_LIBCPP_MSVC) so will affect only this build.
When libcxx can be compiled, it will probably require the current version or
maybe even the next Update of Visual C++ 2013.
Patch by G M!
llvm-svn: 201844
rather than its own type for std::max_align_t. This is particularly
relevant as the types may not be ABI compatible despite users expecting
them to be.
llvm-svn: 201843
with Visual C++ 2013 by making libcxx definition text-identical to yvals.h.
Persumably this definition is for older Visual C++ versions.
In such cases it will still be defined so no functionality change.
Other platforms should not be affected as this is inside
#elif defined(_LIBCPP_MSVC)
Patch by G M!
llvm-svn: 201328
GCC will treat the default function template arguments as a
compilation error if C++0x is not enabled.
This commit workaround the compilation error by moving the
SFINAE check to function argument instead of the template
argument.
llvm-svn: 200523
for libcxx when compiled with Visual C++ on Win32 and Win64.
clang and gcc (MinGW) compilers provide these implementations themselves.
llvm-svn: 198481
GCC does not support strong enum if -std=c++0x is not used.
Without the strong enum, we will see following error:
In file included from libcxx/include/ostream:131:0,
from libcxx/include/sstream:174,
from libcxx/include/complex:247,
from cpp03-headers.cpp:11:
libcxx/include/ios:419:68: error: 'io_errc' is not a class or namespace
libcxx/include/ios:420:66: error: 'io_errc' is not a class or namespace
To workaround this issue, this commit will define
_LIBCPP_HAS_NO_STRONG_ENUMS when we are compiling with
g++ without c++0x.
llvm-svn: 197313
type_traits:3280:31: error: expected primary-expression before 'decltype'
type_traits:3280:29: error: expected ';' at end of member declaration
memory:2415:49: error: function 'std::__1::default_delete<_Tp>::default_delete()'
defaulted on its first declaration must not have an exception-specification
memory:2435:49: error: function 'std::__1::default_delete<_Tp []>::default_delete()'
defaulted on its first declaration must not have an exception-specification
The attached patch defines _LIBCPP_HAS_NO_ADVANCED_SFINAE and
_LIBCPP_HAS_NO_DEFAULTED_FUNCTIONS for gcc version < 4.7, making
the library compile with gcc 4.6.4.
llvm-svn: 195431
functions in src/support/win32/locale_win32.cpp and locale_win32.h,
calling upon vsnprintf for which there is a MingW correct alternative.
Note! __USE_MINGW_ANSI_STDIO is not modified in this patch. In order to
use the __mingw version it must be defined before including the MingW
headers.
llvm-svn: 195044
trivial in C++03, thus making it trivial in both C++03 and C++11.
This patch allows one to opt-in/out of this decision with a macro. You can
choose to have the pair copy constructor always be trivial, or always be
non-trivial. The flag controlling this is now _LIBCPP_TRIVIAL_PAIR_COPY_CTOR.
The client can define this flag to 1, and the pair copy constructor will be
trivial (when possible of course), or to 0, and the pair copy constructor will
be nontrivial.
Default settings for this flag are set in <__config> (as usual). With this
commit the default is _LIBCPP_TRIVIAL_PAIR_COPY_CTOR=1 for all platforms
except __APPLE__, which defaults to _LIBCPP_TRIVIAL_PAIR_COPY_CTOR=0.
llvm-svn: 194742
pair, and a couple of pair-like implementation detail types. The
C++98/03 and 11 standards all specify that the copy constructor of
pair<int, int> is trivial. However as libc++ tracked the draft C++11
standard over the years, this copy constructor became non-trivial, and
then just recently was corrected back to trivial for C++11.
Unfortunately (for libc++1) the Itanium ABI specifies different calling
conventions for trivial and non-trivial copy constructors. Therefore
currently the C++03 libc++ copy constructor for pair<int, int> is ABI
incompatible with the C++11 libc++ copy constructor for pair<int, int>.
This is Bad(tm). This patch corrects the situation by making this copy
constructor trivial in C++03 mode as well.
Just in case it is needed for an incomplete C++11 compiler, libc++
retains the ability to support pair with rvalue references, but without
defaulted special members. However the pair needs non-trivial special
members to implement this special case, (as it did when clang was in
this place a couple of years ago).
During this work a bug was also found and fixed in
is_trivially_constructible.
And there is a minor drive-by fix in <__config> regarding
__type_visibility__.
A test is updated to ensure that the copy constructor of pair<int, int>
is trivial in both C++03 and C++11. This test will necessarily fail for
a compiler that implements rvalue references but not defaulted special
members.
llvm-svn: 194536
The issue this patch seeks to address is that MS's compiler (cl.exe) doesn't support the __attribute__((__weak__)) or __atribute__((__visibility__("default")) syntax; so a solution must be found where cl.exe doesn't see this syntax.
This patch seeks to solve this problem by changing code patterned like this:
__attribute__((__weak__, __visibility__("default")))
void* operator new(size_t size, const std::nothrow_t&) _NOEXCEPT { /*snip*/; return p; }
to code like this:
_LIBCPP_WEAK
void* operator new(size_t size, const std::nothrow_t&) _NOEXCEPT { return p; }
Howard: Thanks for all the comments regarding the default visibility
tag on the definition. I agree it isn't needed, and that there are lots
of other places where it is missing. That being said, I'm not wanting
to rock the boat on that issue right now. So I've added it back to the
definition via _LIBCPP_FUNC_VIS. A later pass dedicated just to this
issue can bring things in to a consistent state one way or the other.
Note that we do not want to have the exact same attributes on the
declaration and defintion in this case. The declaration should not be
marked weak, whereas the definition should (which is what G M's patch
did). I've fully tested on OS X to ensure that the resultant attribute
syntax actually works.
llvm-svn: 192007
The patch touches these files:
locale
array
deque
new
string
utility
vector
__bit_reference
__split_buffer
locale_win32.h
There is no intended functionality change and it is expected that reversing the position of the inline keyword with regard to the other keywords does not change the meaning of anything, least not for apple/Linux etc.
It is intended to make libcxx more consistent with itself and to prevent the 1000 or so
"inline.cpp(3) : warning C4141: 'inline' : used more than once" warnings that MS's cl.exe compiler emits without this patch, i.e. if inline is not the first keyword before a function name etc.
Prefer "inline [other inline related keyword]" over "[other related keyword] inline".
After this patch, libcxx should be consistent to this pattern.
llvm-svn: 191987
iterator, allocator) constructor with the intention of it being
implicitly converted to the allocator type, it is possible for overload
resolution to favour the (iterator, iterator, enable_if) constructor.
Eliminate this possibility by moving the enable_if to one of the
existing arguments and removing the third argument.
llvm-svn: 191145
1. I had been detecting and trapping iterator == and \!= among iterators
in different containers as an error. But the trapping itself is actually
an error.
Consider:
#include <iostream>
#include <vector>
#include <algorithm>
template <class C>
void
display(const C& c)
{
std::cout << "{";
bool first = true;
for (const auto& x : c)
{
if (\!first)
std::cout << ", ";
first = false;
std::cout << x;
}
std::cout << "}\n";
}
int
main()
{
typedef std::vector<int> V;
V v1 = {1, 3, 5};
V v2 = {2, 4, 6};
display(v1);
display(v2);
V::iterator i = std::find(v1.begin(), v1.end(), 1);
V::iterator j = std::find(v2.begin(), v2.end(), 2);
if (*i == *j)
i = j; // perfectly legal
// ...
if (i \!= j) // the only way to check
v2.push_back(*i);
display(v1);
display(v2);
}
It is legal to assign an iterator from one container to another of the
same type. This is required to work. One might want to test whether or
not such an assignment had been made. The way one performs such a check
is using the iterator's ==, \!= operator. This is a logical and necessary
function and does not constitute an error.
2. I had a header circular dependence bug when _LIBCPP_DEBUG2 is defined.
This caused a problem in several of the libc++ tests.
Fixed.
3. There is a serious problem when _LIBCPP_DEBUG2=1 at the moment in that
std::basic_string is inoperable. std::basic_string uses __wrap_iterator
to implement its iterators. __wrap_iterator has been rigged up in debug
mode to support vector. But string hasn't been rigged up yet. This means
that one gets false positives when using std::string in debug mode. I've
upped std::string's priority in www/debug_mode.html.
llvm-svn: 187636
MSVC-specific, MSVCRT-specific, or Windows-specific. Because Clang can
also define _MSC_VER, and MSVCRT is not necessarily the only C runtime,
these macros should not be used interchangeably.
This patch divides all Windows-related bits into the aforementioned
categories. Two new macros are introduced:
- _LIBCPP_MSVC: Defined when compiling with MSVC. Detected using
_MSC_VER, excluding Clang.
- _LIBCPP_MSVCRT: Defined when using the Microsoft CRT. This is the default
when _WIN32 is defined.
This leaves _WIN32 for code using the Windows API.
This also corrects the spelling of _LIBCP_HAS_IS_BASE_OF to _LIBCPP_HAS_IS_BASE_OF.
Nico, please prepare a patch for CREDITS.TXT, thanks.
llvm-svn: 187593
There are actually two debug modes:
1. -D_LIBCPP_DEBUG2 or -D_LIBCPP_DEBUG2=1
This is a relatively expensive debug mode, but very thorough. This is normally what you want to debug with, but may turn O(1) operations into O(N) operations.
2. -D_LIBCPP_DEBUG2=0
This is "debug lite." Only preconditions that can be checked with O(1) expense are checked. For example range checking on an indexing operation. But not iterator validity.
llvm-svn: 187369
unordered_set, however it is not complete yet for unordered_multiset,
unordered_map or unordered_multimap. There has been a lot of work done
for these other three containers, however that work was done just to
keep all of the tests passing.
You can try this out with -D_LIBCPP_DEBUG2. You will have to link to a
libc++.dylib that has been compiled with src/debug.cpp. So far, vector
(but not vector<bool>), list, and unordered_set are treated. I hope to
get the other three unordered containers up fairly quickly now that
unordered_set is done.
The flag _LIBCPP_DEBUG2 will eventually be changed to _LIBCPP_DEBUG, but
not today. This is my second effort at getting debug mode going for
libc++, and I'm not quite yet ready to throw all of the work under the
first attempt away.
The basic design is that all of the debug information is kept in a
central database, instead of in the containers. This has been done as
an attempt to have debug mode and non-debug mode be ABI compatible with
each other. There are some circumstances where if you construct a
container in an environment without debug mode and pass it into debug
mode, the checking will get confused and let you know with a readable
error message. Passing containers the other way: from debug mode out to
a non-debugging mode container should be 100% safe (at least that is the
goal).
llvm-svn: 186991
implementation and all of the char buffers readily have their
allocated size available, so we can easily use snprintf_l instead of
sprintf_l.
This avoids OpenBSD's linker warnings against using sprintf and
vsprintf.
Howard: Please consider a patch for CREDITS.TXT
llvm-svn: 185457
The tests use placement new to check that atomic values get properly zero-initialized. I had to modify the atomic_is_lock_free test, because default initialization of an object of const type 'const A' (aka 'const atomic<int>') requires a user-provided default constructor.
llvm-svn: 180945
implementation of std::is_polymorphic does this:
template <class _Tp> struct __is_polymorphic1 : public _Tp {};
... and that g++ rejects this if _Tp has an inaccessible virtual destructor
(because __is_polymorphic1<_Tp> would have a deleted virtual destructor
overriding _Tp's non-deleted destructor). Clang was failing to reject this;
I've fixed that in r178563, but that causes libc++'s corresponding test
case to fail with both clang and gcc when using the fallback
implementation. The fallback code also incorrectly rejects final types.
The attached patch fixes the fallback implementation of is_polymorphic; we
now use dynamic_cast's detection of polymorphic class types rather than
trying to determine if adding a virtual function makes the type larger:
enable_if<sizeof((_Tp*)dynamic_cast<const volatile
void*>(declval<_Tp*>())) != 0, ...>
Two things of note here:
* the (_Tp*) cast is necessary to work around bugs in Clang and g++ where
we otherwise don't instantiate the dynamic_cast (filed as PR15656)
* the 'const volatile' is here to treat is_polymorphic<cv T> as true for a
polymorphic class type T -- my reading of the standard suggests this is
incorrect, but it matches our builtin __is_polymorphic and gcc
llvm-svn: 178576
Eric Fiselier