| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
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
|
|
|
|
|
|
|
| |
The test was marked as UNSUPPORTED for clang-6 and clang-6, instead of
clang-6 and clang-7.
llvm-svn: 368666
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
D64914 added support for applying [[nodiscard]] to constructors. This
commit uses that capability to flag incorrect uses of std::lock_guard
where one forgets to actually create a variable for the lock_guard.
rdar://45790820
Reviewers: mclow.lists, EricWF
Subscribers: christof, jkorous, dexonsmith, libcxx-commits, Quuxplusone, lebedev.ri
Tags: #libc
Differential Revision: https://reviews.llvm.org/D65900
llvm-svn: 368664
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit adds a __pstl_config_site header that contains the value of
macros specified at CMake configuration time. It works similarly to
libc++'s __config_site header, except we always include it as a separate
file instead of concatenating it to the main configuration header.
It is necessary to thread the includes for that header into libc++'s
lit configuration, otherwise we'd be requiring an installation step
prior to running the test suite.
llvm-svn: 368284
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This commit allows specifying LIBCXX_ENABLE_PARALLEL_ALGORITHMS when
configuring libc++ in CMake. When that option is enabled, libc++ will
assume that the PSTL can be found somewhere on the CMake module path,
and it will provide the C++17 parallel algorithms based on the PSTL
(that is assumed to be available).
The commit also adds support for running the PSTL tests as part of
the libc++ test suite.
The first attempt to commit this failed because it exposed a bug in the
tests for modules. Now that this has been fixed, it should be safe to
commit this.
Reviewers: EricWF
Subscribers: mgorny, christof, jkorous, dexonsmith, libcxx-commits, mclow.lists, EricWF
Tags: #libc
Differential Revision: https://reviews.llvm.org/D60480
llvm-svn: 367903
|
|
|
|
|
|
|
|
|
| |
Some modules builds are issuing buggy diagnostics. The cause of which is
TBD.
This reverts commit r@367770.
llvm-svn: 367777
|
|
|
|
|
|
|
|
|
|
|
| |
There are a handful of standard library types that are intended
to support CTAD but don't need any explicit deduction guides to
do so.
This patch adds a dummy deduction guide to those types to suppress
-Wctad-maybe-unsupported (which gets emitted in user code).
llvm-svn: 367770
|
|
|
|
|
|
|
|
| |
I have upcoming changes that modify how deque handles spare blocks.
This cleanup is intended to make those changes easier to review
and understand. This patch should have NFC.
llvm-svn: 367631
|
|
|
|
| |
llvm-svn: 367606
|
|
|
|
|
|
|
|
|
|
|
| |
Previously these types rehashed to a table of 193 elements
upon construction. But this is non-ideal, first because default
constructors should not allocate unless necessary, and second
because 193 is big and can waste a bunch of memory.
This number had previously been chosen to match GCC's implementation.
llvm-svn: 367605
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
[cpp.predefined]p2:
__STDCPP_THREADS__
Defined, and has the value integer literal 1, if and only if a program
can have more than one thread of execution .
Also define it only if it's not defined already, since it's supposed
to be defined by the compiler.
Also move it from thread to __config (which requires setting it only
if _LIBCPP_HAS_NO_THREADS is not defined).
Part of PR33230. The intent is to eventually make the compiler define
this instead.
llvm-svn: 367316
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This issue was detected by ASan in one of our tests. This test manually
invokes basic_filebuf::cloe(). fclose(__h.release() returned a non-zero
exit status, so __file_ wasn't set to 0. Later when basic_filebuf
destructor ran, we would enter the if (__file_) block again leading to
heap-use-after-free error.
The POSIX specification for fclose says that independently of the return
value, fclose closes the underlying file descriptor and any further
access (including another call to fclose()) to the stream results in
undefined behavior. This is exactly what happened in our test case.
To avoid this issue, we have to always set __file_ to 0 independently of
the fclose return value.
Differential Revision: https://reviews.llvm.org/D64979
llvm-svn: 366730
|
|
|
|
|
|
|
|
|
|
| |
AppleClang 9
Some minor versions of AppleClang 9 appear not to fail the test. It's
such a mess that the only sane thing to do is to mark the test as
UNSUPPORTED.
llvm-svn: 366606
|
|
|
|
|
|
|
| |
This reverts r366593, which caused unforeseen breakage on the build bots.
I'm reverting until the problems have been figured out and fixed.
llvm-svn: 366603
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This commit allows specifying LIBCXX_ENABLE_PARALLEL_ALGORITHMS when
configuring libc++ in CMake. When that option is enabled, libc++ will
assume that the PSTL can be found somewhere on the CMake module path,
and it will provide the C++17 parallel algorithms based on the PSTL
(that is assumed to be available).
The commit also adds support for running the PSTL tests as part of
the libc++ test suite.
Reviewers: rodgert, EricWF
Subscribers: mgorny, christof, jkorous, dexonsmith, libcxx-commits, mclow.lists, EricWF
Tags: #libc
Differential Revision: https://reviews.llvm.org/D60480
llvm-svn: 366593
|
|
|
|
|
|
|
| |
Without the link flags, the test always fails on Linux. For some reason,
however, it works on Darwin -- which is why it wasn't caught at first.
llvm-svn: 366579
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This is effectively a revert of r344616, which was a partial fix for
PR38964 (compilation of <string> with GCC in C++03 mode). However, that
configuration is explicitly not supported anymore and that partial fix
breaks compilation with Clang when per-TU insulation is provided.
PR42676
rdar://52899715
Reviewers: mclow.lists, EricWF
Subscribers: christof, jkorous, dexonsmith, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D64941
llvm-svn: 366567
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: http://llvm.org/PR39606
Reviewers: Quuxplusone
Subscribers: christof, dexonsmith, libcxx-commits
Differential Revision: https://reviews.llvm.org/D54410
llvm-svn: 366484
|
|
|
|
|
|
| |
rdar://53015486
llvm-svn: 366359
|
|
|
|
|
|
|
|
|
| |
In r361572, we introduced library support for C++20 destroying delete
and decided to only define the library feature-test macro when the
compiler supports the underlying language feature. This patch reworks
the tests to mirror that.
llvm-svn: 366263
|
|
|
|
|
|
|
| |
The tests for unordered_set and unordered_multiset were missing UNSUPPORTED
markup for Apple Clang 9.1, which is still being used on some CI bots.
llvm-svn: 366259
|
|
|
|
|
|
| |
P0458R2, adding contains to map, multimap, unordered_map, unordered_multimap, set, multiset, unordered_set, and unordered_multiset.
llvm-svn: 366170
|
|
|
|
|
|
|
|
| |
Thanks to Arthur O'Dwyer for the patch.
Differential Revision: https://reviews.llvm.org/D58590
llvm-svn: 366124
|
|
|
|
|
|
|
|
|
|
| |
In particular, improve the compile time of the overload set builder
that variant uses to determine which alternative to construct.
Instead of having the __overload type construct itself recursively,
this patch uses a flat construction for the overload set.
llvm-svn: 366033
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 365923
|
|
|
|
| |
llvm-svn: 365856
|
|
|
|
|
|
| |
internal use pre-C++20. NFC for external users
llvm-svn: 365854
|
|
|
|
|
|
|
|
| |
When assigning an initializer list into set/map, libc++ would
leak memory if the initializer list contained equivalent keys
because we failed to check if the insertion was successful.
llvm-svn: 365840
|
|
|
|
|
|
|
| |
Thanks to Arthur O'Dwyer for the patch.
Differential Revision: https://reviews.llvm.org/D58617
llvm-svn: 365788
|
|
|
|
|
|
| |
undoes that bit of D58332. Thanks to Mikhail Maltsev for pointing this out
llvm-svn: 365290
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently std::mutex has a constexpr constructor, but a non-trivial
destruction.
The constexpr constructor is required to ensure the construction of a
mutex with static storage duration happens at compile time, during
constant initialization, and not during dynamic initialization.
This means that static mutex's are always initialized and can be used
safely during dynamic initialization without the "static initialization
order fiasco".
A trivial destructor is important for similar reasons. If a mutex is
used during dynamic initialization it might also be used during program
termination. If a static mutex has a non-trivial destructor it will be
invoked during termination. This can introduce the "static
deinitialization order fiasco".
Additionally, function-local statics emit a guard variable around
non-trivially destructible types. This results in horrible codegen and
adds a runtime cost to every call to that function. non-local static's
also result in slightly worse codegen but it's not as big of a problem.
Example codegen can be found here: https://goo.gl/3CSzbM
Note: This optimization is not safe with every pthread implementation.
Some implementations allocate on the first call to pthread_mutex_lock
and free the allocation in pthread_mutex_destroy.
Also, changing the triviality of the destructor is not an ABI break.
At least to the best of my knowledge :-)
llvm-svn: 365273
|
|
|
|
|
|
| |
bit of D58332. Thanks to Mikhail Maltsev for pointing this out
llvm-svn: 365261
|
|
|
|
|
|
| |
and iter_swap are updated (with tests).
llvm-svn: 365238
|
|
|
|
|
|
| |
https://reviews.llvm.org/D63051
llvm-svn: 365080
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
language versions and w/o any compiler support. 'Working', in this case, means that it returns false in those cases.
llvm-svn: 364873
|