| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
llvm-svn: 325740
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Currently std::asinh and std::acosh use std::pow to compute x^2. This
results in a significant error when computing e.g. asinh(i) or
acosh(-1).
This patch expresses x^2 directly via x.real() and x.imag(), like it
is done in libstdc++/glibc, and adds tests that checks the accuracy.
Reviewers: EricWF, mclow.lists
Reviewed By: mclow.lists
Subscribers: christof, cfe-commits
Differential Revision: https://reviews.llvm.org/D41629
llvm-svn: 325510
|
|
|
|
| |
llvm-svn: 325205
|
|
|
|
|
|
| |
2GB. (like say 32-bit big-endian)
llvm-svn: 325147
|
|
|
|
| |
llvm-svn: 325028
|
|
|
|
| |
llvm-svn: 324959
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Patch from ngolovliov@gmail.com
Reviewed as: https://reviews.llvm.org/D42344
As described in llvm.org/PR30959, the current
implementation of std::{map, key}::{count, equal_range} in libcxx is
non-conforming. Quoting the C++14 standard [associative.reqmts]p3
> The phrase “equivalence of keys” means the equivalence relation imposed by
> the comparison and not the operator== on keys. That is, two keys k1 and k2 are
> considered to be equivalent if for the comparison object comp,
> comp(k1, k2) == false && comp(k2, k1) == false.
In the same section, the requirements table states the following:
> a.equal_range(k) equivalent to make_pair(a.lower_bound(k), a.upper_bound(k))
> a.count(k) returns the number of elements with key equivalent to k
The behaviour of libstdc++ seems to conform to the standard here.
llvm-svn: 324799
|
|
|
|
| |
llvm-svn: 324640
|
|
|
|
| |
llvm-svn: 324624
|
|
|
|
|
|
| |
unsupported, b/c they don't have deduction guides, even in C++17 mode
llvm-svn: 324619
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Currently libc++ implements some operations on valarray by using the
resize method. This method has a parameter with a default value.
Because of this, valarray may spuriously construct and destruct
objects of valarray's element type.
This patch fixes this issue and adds corresponding test cases.
Reviewers: EricWF, mclow.lists
Reviewed By: mclow.lists
Subscribers: rogfer01, cfe-commits
Differential Revision: https://reviews.llvm.org/D41992
llvm-svn: 324596
|
|
|
|
|
|
| |
with old bots
llvm-svn: 324573
|
|
|
|
| |
llvm-svn: 324569
|
|
|
|
| |
llvm-svn: 324566
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
sizeof(T)>sizeof(long long)'. We were mishandling the small-string optimization calculations for very large 'characters'. This may be an ABI change (change the size of) strings of very large 'characters', but since they never worked, I'm not too concerned.
llvm-svn: 324531
|
|
|
|
| |
llvm-svn: 324529
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
type aliases, conjunction/disjunction, apply, etc. See https://libcxx.llvm.org/TS_deprecation.html
llvm-svn: 324423
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
https://libcxx.llvm.org/TS_deprecation.html
llvm-svn: 324290
|
|
|
|
|
|
|
|
|
| |
This patch removes the noexcept declaration from filesystem
operations which require creating temporary paths or
creating a directory iterator. Either of these operations
can throw.
llvm-svn: 324192
|
|
|
|
| |
llvm-svn: 324190
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Because path can be constructed from a ton of different types, including string
and wide strings, this caused it's streaming operators to suck up all sorts
of silly types via silly conversions. For example:
using namespace std::experimental::filesystem::v1;
std::wstring w(L"wide");
std::cout << w; // converts to path.
This patch tentatively adopts the resolution to LWG2989 and fixes the issue
by making the streaming operators friends of path.
llvm-svn: 324189
|
|
|
|
|
|
|
| |
Previously copy_file didn't handle the case where the input and
output were the same file.
llvm-svn: 324187
|
|
|
|
| |
llvm-svn: 324186
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 324165
|
|
|
|
|
|
|
|
|
|
|
| |
When Clang encounters an already invalid class declaration, it can
emit incorrect diagnostics about the exception specification on
some of its members. This patch temporarily works around that
incorrect diagnostic.
The clang bug was introduced in r324062.
llvm-svn: 324164
|
|
|
|
|
|
|
|
|
| |
Clang previously reported an empty union as having a unique object
representation. This was incorrect and was fixed in a recent Clang commit.
This patch fixes the libc++ tests.
llvm-svn: 324153
|
|
|
|
| |
llvm-svn: 324033
|
|
|
|
|
|
|
|
| |
Patch by Chris Kennelly!
Differential Revision: https://reviews.llvm.org/D41746
llvm-svn: 324020
|
|
|
|
|
|
| |
https://libcxx.llvm.org/TS_deprecation.html
llvm-svn: 323979
|
|
|
|
|
|
| |
https://libcxx.llvm.org/TS_deprecation.html
llvm-svn: 323975
|
|
|
|
|
|
| |
https://libcxx.llvm.org/TS_deprecation.html
llvm-svn: 323972
|
|
|
|
|
|
| |
https://libcxx.llvm.org/TS_deprecation.html
llvm-svn: 323971
|
|
|
|
|
|
| |
traits match the character type. This is a requirement on the user - now we get consistent failures at compile time instead of incomprehensible error messages or runtime failures. This is also LWG#2994 - not yet adopted.
llvm-svn: 323945
|
|
|
|
| |
llvm-svn: 323918
|
|
|
|
|
|
| |
C++17 mode. This is LWG#3009, coming up for a vote in JAX - but we already do it, just don't have tests
llvm-svn: 323719
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
According to [1], forms 2 and 4 of std::is_permutation should use the passed in
binary predicate to compare elements. operator== should only be used for forms
1 and 3 which do not take a binary predicate.
This CL fixes forms 2 and 4 which relied on operator== for some comparisons.
[1] http://en.cppreference.com/w/cpp/algorithm/is_permutation
Patch by Thomas Anderson!
Differential Revision: https://reviews.llvm.org/D42518
llvm-svn: 323563
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Code on Windows expects to be able to do:
#define _USE_MATH_DEFINES
#include <math.h>
and receive the definitions of mathematical constants, even if <math.h>
has previously been included. To support this scenario, re-include
<math.h> every time the wrapper header is included.
Differential Revision: https://reviews.llvm.org/D42403
llvm-svn: 323490
|
|
|
|
|
|
|
|
|
|
|
|
| |
There was a bug in the implementation of splice where the container
sizes were updated before decrementing one of the iterators. Afterwards,
the result of decrementing the iterator was flagged as UB by the debug
implementation because the container was reported to be empty.
This patch fixes that bug by delaying the updating of the container
sizes until after the iterators have been correctly constructed.
llvm-svn: 323390
|
|
|
|
|
|
| |
decltype(auto)
llvm-svn: 323385
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
binding in std::tuple.
Summary:
See https://bugs.llvm.org/show_bug.cgi?id=20855
Libc++ goes out of it's way to diagnose `std::tuple` constructions which are UB due to lifetime bugs caused by reference creation. For example:
```
// The 'const std::string&' is created *inside* the tuple constructor, and its lifetime is over before the end of the constructor call.
std::tuple<int, const std::string&> t(std::make_tuple(42, "abc"));
```
However, we are over-aggressive and we incorrectly diagnose cases such as:
```
void foo(std::tuple<int const&, int const&> const&);
foo(std::make_tuple(42, 42));
```
This patch fixes the incorrectly diagnosed cases, as well as converting the diagnostic to use the newly added Clang trait `__reference_binds_to_temporary`. The new trait allows us to diagnose cases we previously couldn't such as:
```
std::tuple<int, const std::string&> t(42, "abc");
```
Reviewers: rsmith, mclow.lists
Reviewed By: rsmith
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D41977
llvm-svn: 323380
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Currently when a regular expression contains an invalid character
class name std::regex constructors throw an std::regex_error with
std::regex_constants::error_brack code.
This patch changes the code to std::regex_constants::error_ctype and
adds a test.
Reviewers: EricWF, mclow.lists
Reviewed By: mclow.lists
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D42291
llvm-svn: 323322
|
|
|
|
| |
llvm-svn: 323306
|
|
|
|
|
|
| |
https://reviews.llvm.org/D35472
llvm-svn: 323296
|
|
|
|
|
|
|
|
|
|
|
|
| |
filenames on Windows.
This is an MSVC standard library extension. It seems like a reasonable
enough extension to me because wchar_t* is the native format for
filenames on that platform.
Differential Revision: https://reviews.llvm.org/D42225
llvm-svn: 323170
|
|
|
|
| |
llvm-svn: 323159
|