The use of the `&& ...` fold expression in std::array's deduction guides
recursively builds a set of binary operator expressions of depth N where
`N` is the number of elements in the initializer.

This is problematic because arrays may be large, and instantiation
depth is limited.

This patch addresses the issue by flattening the SFINAE using
the existing `__all` type trait.

(cherry picked from commit c6eb584c)

Similarly to https://reviews.llvm.org/rL350972, this revision changes
std::tuple_element from class to struct.

Fixes PR41331.
Thanks to Jan Wilken Dörrie for the patch.

Differential Revision: https://reviews.llvm.org/D60069

llvm-svn: 357411

Mark 'front()' and 'back()' as noexcept for array/deque/string/string_view. These are just rebranded 'operator[]', and should be noexcept like it is.

llvm-svn: 356435

Add noexcept to operator[] for array and deque. This is an extension. We already do this for string and string_view. This should give better codegen inside of noexcept functions.

llvm-svn: 356209

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

llvm-svn: 350972

Implement the infrastructure for feature-test macros. Very few actual feature test macros, though. Reviewed as: https://reviews.llvm.org/D51955

llvm-svn: 342073

llvm-svn: 338668

llvm-svn: 332768

An array T[1] isn't necessarily the same say when it's
a member of a struct. This patch addresses that problem and corrects
the tests to deal with it.

llvm-svn: 324545

Summary:
This patch fixes llvm.org/PR35491 and LWG2157  (https://cplusplus.github.io/LWG/issue2157)

The fix attempts to maintain ABI compatibility by replacing the array with a instance of `aligned_storage`.

Reviewers: mclow.lists, EricWF

Reviewed By: EricWF

Subscribers: lichray, cfe-commits

Differential Revision: https://reviews.llvm.org/D41223

llvm-svn: 324526

Revert "[libc++] Fix PR35491 - std::array of zero-size doesn't work with non-default constructible types."
Revert "Fix initialization of array<const T, 0> with GCC."
Revert "Make array<const T, 0> non-CopyAssignable and make swap and fill ill-formed."

This reverts commit r324182, r324185, and r324194 which were causing issues with zero-length std::arrays.

llvm-svn: 324309

Previously, when handling zero-sized array of const objects we
used a const version of aligned_storage_t, which is not an array type.
However, GCC complains about initialization of the form: array<const T, 0> arr = {};

This patch fixes that bug by making the dummy object used to represent
the zero-sized array an array itself. This avoids GCC's complaints
about the uninitialized const member.

llvm-svn: 324194

The standard isn't exactly clear how std::array should handle zero-sized arrays
with const element types. In particular W.R.T. copy assignment, swap, and fill.

This patch takes the position that those operations should be ill-formed,
and makes changes to libc++ to make it so.

This follows up on commit r324182.

llvm-svn: 324185

Summary:
This patch fixes llvm.org/PR35491 and LWG2157  (https://cplusplus.github.io/LWG/issue2157)

The fix attempts to maintain ABI compatibility by replacing the array with a instance of `aligned_storage`.

Reviewers: mclow.lists, EricWF

Reviewed By: EricWF

Subscribers: lichray, cfe-commits

Differential Revision: https://reviews.llvm.org/D41223

llvm-svn: 324182

First part of P0600 - '[[nodiscard] in the standard library'. Mark the 'empty()' methods of all the containers as nodiscard. If you're calling empty() w/o looking at the result, you probably meanto to call 'clear()'. c++2a only

llvm-svn: 318269

[array.tuple]/1 says that instantiating tuple_element<N, array<T, M>> is ill-formed if N >= M.  We didn't do that. Add a static_assert to cause a failure, and a test that checks that we failed

llvm-svn: 305191

Summary:
This patch improves how libc++ handles min/max macros within the headers. Previously libc++ would undef them and emit a warning.
This patch changes libc++ to use `#pragma push_macro`  to save the macro before undefining it, and `#pragma pop_macro` to restore the macros and the end of the header.

Reviewers: mclow.lists, bcraig, compnerd, EricWF

Reviewed By: EricWF

Subscribers: cfe-commits, krytarowski

Differential Revision: https://reviews.llvm.org/D33080

llvm-svn: 304357

llvm-svn: 300412

llvm-svn: 292091

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

Implement the last bit of P0031: 'A Proposal to Add Constexpr Modifiers to reverse_iterator, move_iterator, array and Range Access' for C++17

llvm-svn: 290976

Add an _LIBCPP_NORETURN inline function named __throw_XXX for each exception type we define. They either construct and throw the exception, or abort() (if exceptions are disabled). Use these functions everywhere instead of assert()ing when exceptions are disabled. WARNING: This is a behavior change - but only with exceptions disabled.  Reviewed as: https://reviews.llvm.org/D23855.

llvm-svn: 279744

llvm-svn: 267079

non-member swap for array was mistakenly taking const ref params. Fixed and added test. Thanks to Ben Craig for the catch

llvm-svn: 262866

Review: http://reviews.llvm.org/D14839
llvm-svn: 255941

llvm-svn: 253592

[libcxx] Move tuple_size and tuple_element overloads for pair and array out of !defined(_LIBCPP_HAS_NO_VARIADICS) block.

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

G M: Changes all references to "x inline" to "inline x" where x = _libcpp_always_inline or _libcpp_inline_visibility macros.

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

Nico Rieck:  this patch series fixes visibility issues on Windows as explained in <http://lists.cs.uiuc.edu/pipermail/cfe-dev/2013-August/031214.html>.

llvm-svn: 188192

llvm-svn: 186525

No functionality change at this time.  I've split _LIBCPP_VISIBLE up into two flags: _LIBCPP_TYPE_VIS and _LIBCPP_FUNC_VIS.  This is in preparation for taking advantage of clang's new __type_visibility__ attribute.

llvm-svn: 176593

llvm-svn: 170435

llvm-svn: 160564

llvm-svn: 142235

llvm-svn: 134190

Experimental support for a meaningful __is_swappable<T>::value.  This does not appear to be strictly needed for correct functioning of the library.  If it causes any problems, I'd rather pull it sooner rather than later.

llvm-svn: 132421

llvm-svn: 132359

llvm-svn: 119545

llvm-svn: 119395