| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
llvm-svn: 371880
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D66544
llvm-svn: 369597
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
LLVM uses .h as its extension for header files.
Files renamed using:
for f in libcxx/test/support/*.hpp; do git mv $f ${f%.hpp}.h; done
References to the files updated using:
for f in $(git diff master | grep 'rename from' | cut -f 3 -d ' '); do
a=$(basename $f);
echo $a;
rg -l $a libcxx | xargs sed -i '' "s/$a/${a%.hpp}.h/";
done
HPP include guards updated manually using:
for f in $(git diff master | grep 'rename from' | cut -f 3 -d ' '); do
echo ${f%.hpp}.h ;
done | xargs mvim
Differential Revision: https://reviews.llvm.org/D66104
llvm-svn: 369481
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The resolution of LWG 3199 makes sure that input-streaming into an empty bitset
does not set the failbit on the input stream.
Reviewers: mclow.lists, EricWF
Subscribers: christof, jkorous, dexonsmith, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D65105
llvm-svn: 369422
|
| |
|
|
|
|
| |
This test doesn't fail on all patch levels of AppleClang 11
llvm-svn: 369420
|
| |
|
|
|
|
|
|
| |
In r368882, I enabled those tests for all AppleClang's above version 9.
However, it turns out that the feature is only supported starting with
AppleClang 10.0.1, not AppleClang 10.0.0. This commit fixes that hole.
llvm-svn: 369409
|
| |
|
|
| |
llvm-svn: 369280
|
| |
|
|
| |
llvm-svn: 368914
|
| |
|
|
|
|
|
|
| |
Like CTAD for std::unordered_set, AppleClang 9's support for CTAD is
insufficient. I suspect the corresponding LLVM Clang is broken too,
but we don't seem to have testers using that Clang.
llvm-svn: 368911
|
| |
|
|
|
|
| |
AppleClang supports those literals starting in version 10.0.1.
llvm-svn: 368882
|
| |
|
|
|
|
|
| |
The operator""y and operator""d will eventually be supported by
AppleClang, but no released version supports them at the moment.
llvm-svn: 368749
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
We were using implicit deduction guides instead of explicit ones,
however the implicit ones don't do work anymore when changing the
constructors.
This commit adds the actual guides specified in the Standard to make
libc++ (1) closer to the Standard and (2) more resistent to changes
in std::tuple's constructors.
Reviewers: Quuxplusone
Subscribers: christof, jkorous, dexonsmith, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D65225
llvm-svn: 368599
|
| |
|
|
| |
llvm-svn: 368299
|
| |
|
|
| |
llvm-svn: 367268
|
| |
|
|
|
|
| |
had not been reduced.s
llvm-svn: 367120
|
| |
|
|
|
|
| |
Sunday. Add accessors 'c_encoding' and 'iso_encoding' to provide different interpretations of the weekday. Remove 'operator unsigned'
llvm-svn: 366981
|
| |
|
|
|
|
| |
functionality from 'type-traits' to 'bit'. No other change. The reason that this is 'partial' is that P1621 also recommends a feature-test macro, but I don't have the value for that one yet. In a month or so, I'll add that
llvm-svn: 366776
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Summary: http://llvm.org/PR39606
Reviewers: Quuxplusone
Subscribers: christof, dexonsmith, libcxx-commits
Differential Revision: https://reviews.llvm.org/D54410
llvm-svn: 366484
|
| |
|
|
| |
llvm-svn: 366032
|
| |
|
|
|
|
|
| |
The test was brittle since it only went boom for one specific type, when
really it should go boom for all of them.
llvm-svn: 366025
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The standard disallows narrowing conversions when constructing a variant.
This is checked by attempting to perform braced initialization of the
destination type from the argument type. However, braced initialization
can force the compiler (mostly clang) to eagerly instantiate the
constructors of the destintation type -- which can lead to errors in
a non-immediate context.
However, as variant is currently specified, the narrowing checks only
observably apply when the destination type is arithmetic. Meaning we can
skip the check for class types. Hense avoiding the hard errors.
In order to cause fewer build breakages, this patch avoids the narrowing
check except when the destination type is arithmetic.
llvm-svn: 366022
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously we implemented all one trillion tuple-like constructors using
a single generic overload. This worked fairly well, except that it
differed in behavior from the standard version because it didn't
consider both T&& and T const&. This was observable for certain
types.
This patch addresses that issue by splitting the generic constructor
in two. We now provide both T&& and T const& versions of the
tuple-like constructors (sort of).
llvm-svn: 365973
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The paper P0608R3 - "A sane variant converting constructor" disallows
narrowing conversions in variant. It was meant to address this
surprising problem:
std::variant<std::string, bool> v = "abc";
assert(v.index() == 1); // constructs a bool.
However, it also disables every potentially narrowing conversion. For
example:
variant<unsigned> v = 0; // ill-formed
variant<string, double> v2 = 42; // ill-formed (int -> double narrows)
These latter changes break code. A lot of code. Within Google it broke
on the order of a hundred thousand target with thousands of root causes
responsible for the breakages.
Of the breakages related to the narrowing restrictions, none of them
exposed outstanding bugs. However, the breakages caused by boolean
conversions (~13 root causes), all but one of them were bugs.
For this reasons, I am adding a flag to disable the narrowing conversion
changes but not the boolean conversions one.
One purpose of this flag is to allow users to opt-out of breaking changes
in variant until the offending code can be cleaned up. For non-trivial
variant usages the amount of cleanup may be significant.
This flag is also required to support automated tooling, such as
clang-tidy, that can automatically fix code broken by this change.
In order for clang-tidy to know the correct alternative to construct,
it must know what alternative was being constructed previously, which
means running it over the old version of std::variant.
Because this change breaks so much code, I will be implementing the
aforementioned clang-tidy check in the very near future.
Additionally I'm plan present this new information to the committee so they can
re-consider if this is a breaking change we want to make.
I think libc++ should very seriously consider pulling this change
before the 9.0 release branch is cut. But that's a separate discussion
that I will start on the lists.
For now this is the minimal first step.
llvm-svn: 365960
|
| |
|
|
|
|
| |
and iter_swap are updated (with tests).
llvm-svn: 365238
|
| |
|
|
|
|
|
|
|
|
|
|
| |
types.
It seems some people like to write types that can explicitly convert
to anything, but cannot be used to explicitly construct anything.
This patch makes tuple tolerate such types, as is required
by the standard.
llvm-svn: 365074
|
| |
|
|
| |
llvm-svn: 364842
|
| |
|
|
|
|
| |
assignment operator. Fixes PR38638. Thanks to Jonathan Wakely for the report
llvm-svn: 364574
|
| |
|
|
| |
llvm-svn: 364241
|
| |
|
|
| |
llvm-svn: 364239
|
| |
|
|
| |
llvm-svn: 364161
|
| |
|
|
|
|
| |
https://reviews.llvm.org/D63574
llvm-svn: 364094
|
| |
|
|
| |
llvm-svn: 364065
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These functions are key to allowing the use of rvalues and variadics
in C++03 mode. Everything works the same as in C++11, except for one
tangentially related case:
struct T {
T(T &&) = default;
};
In C++11, T has a deleted copy constructor. But in C++03 Clang gives
it both a move and a copy constructor. This seems reasonable enough
given the extensions it's using.
The other changes in this patch were the minimal set required
to keep the tests passing after the move/forward change. Most notably
the removal of the `__rv<unique_ptr>` hack that was present
in an attempt to make unique_ptr move only without language support.
llvm-svn: 364063
|
| |
|
|
| |
llvm-svn: 364058
|
| |
|
|
| |
llvm-svn: 364057
|
| |
|
|
|
|
| |
The next step is to get move and forward working in C++03.
llvm-svn: 364053
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Re-apply the change which was reverted in r363764 as-is after
breakages being resolved. Thanks Eric Fiselier for working
hard on this.
See also: https://bugs.llvm.org/show_bug.cgi?id=42330
Differential Revision: https://reviews.llvm.org/D44865
llvm-svn: 363993
|
| |
|
|
|
|
|
| |
The change caused a large number of compiler failures in
Google's codebase. People need time to evaluate the impact.
llvm-svn: 363764
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Prefer user-defined conversions over narrowing conversions and conversions to bool.
References:
http://wg21.link/p0608
Reviewers: EricWF, mpark, mclow.lists
Reviewed By: mclow.lists
Subscribers: zoecarver, ldionne, libcxx-commits, cfe-commits, christof
Differential Revision: https://reviews.llvm.org/D44865
llvm-svn: 363692
|
| |
|
|
| |
llvm-svn: 363689
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This was found to be broken on Clang trunk. This is a revert of the
following commits (the subsequent commits added XFAILs to the tests
that were missing from the original submission):
r362986: Implement deduction guides for map/multimap.
r363014: Add some XFAILs
r363097: Add more XFAILs
r363197: Add even more XFAILs
llvm-svn: 363688
|
| |
|
|
| |
llvm-svn: 363589
|
| |
|
|
| |
llvm-svn: 363111
|
| |
|
|
|
|
| |
didn't know existed
llvm-svn: 363097
|
| |
|
|
|
|
| |
compiler intrinsic which was broken in many clangs, have lots of XFAILs.
llvm-svn: 363029
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
It is a bugfix proposal for https://bugs.llvm.org/show_bug.cgi?id=42166.
`std::to_chars` appends leading zeros if input 64-bit value has 9, 10 or 11 digits.
According to documentation `std::to_chars` must not append leading zeros:
https://en.cppreference.com/w/cpp/utility/to_chars
Changeset should not affect `std::to_chars` performance:
http://quick-bench.com/CEpRs14xxA9WLvkXFtaJ3TWOVAg
Unit test that `std::from_chars` supports compatibility for both `std::to_chars` outputs (previous and fixed one) already exists:
https://github.com/llvm-mirror/libcxx/blob/1f60111b597e5cb80a4513ec86f79b7e137f7793/test/std/utilities/charconv/charconv.from.chars/integral.pass.cpp#L63
Reviewers: lichray, mclow.lists, ldionne, EricWF
Reviewed By: lichray, mclow.lists
Subscribers: zoecarver, christof, dexonsmith, libcxx-commits
Differential Revision: https://reviews.llvm.org/D63047
llvm-svn: 362967
|
| |
|
|
| |
llvm-svn: 362861
|
| |
|
|
|
|
|
|
|
|
|
| |
Some tests require `TEST_WORKAROUND_CONSTEXPR_IMPLIES_NOEXCEPT`, but they
did not include the header that defines that macro.
Thanks to Michael Park for the patch.
Differential Revision: https://reviews.llvm.org/D62920
llvm-svn: 362660
|
| |
|
|
|
|
| |
Thanks to Zoe for the (big, but simple) patch. NFC intended.
llvm-svn: 362252
|
| |
|
|
| |
llvm-svn: 360911
|