| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 c6eb584c64872fbb779df14acd31c1f3947f6e52)
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
These are just rebranded 'operator[]', and should be noexcept like it is.
llvm-svn: 356435
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
feature test macros, though. Reviewed as: https://reviews.llvm.org/D51955
llvm-svn: 342073
|
|
|
|
| |
llvm-svn: 338668
|
|
|
|
|
|
| |
https://reviews.llvm.org/D46964
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
constructible types.
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
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
constructible types.
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
|
|
|
|
|
|
| |
'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
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
reverse_iterator, move_iterator, array and Range Access' for C++17
llvm-svn: 290976
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
added test. Thanks to Ben Craig for the catch
llvm-svn: 262866
|
|
|
|
|
|
|
| |
K-Ballo.
Review: http://reviews.llvm.org/D14839
llvm-svn: 255941
|
|
|
|
|
|
| |
K-ballo for the patch
llvm-svn: 253592
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
_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
|
|
|
|
|
|
| |
explained in <http://lists.cs.uiuc.edu/pipermail/cfe-dev/2013-August/031214.html>.
llvm-svn: 188192
|
|
|
|
| |
llvm-svn: 186525
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
bounds" calls
llvm-svn: 170435
|
|
|
|
| |
llvm-svn: 160564
|
|
|
|
| |
llvm-svn: 142235
|
|
|
|
| |
llvm-svn: 134190
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 114470
|
|
|
|
| |
llvm-svn: 111750
|
|
|
|
| |
llvm-svn: 103516
|
|
llvm-svn: 103490
|