These don't seem to have any function in the test.
The non_regular_file one seems to have been added in
0f8c8f59df, without any apparent
purpose there.
Differential Revision: https://reviews.llvm.org/D97083
This patch ensures that SFINAE is used to delete assignment operators in pair and tuple based on issue 2729.
Differential Review: https://reviews.llvm.org/D62454
This matches what MS STL returns; in std::filesystem, forward slashes
are considered generic dir separators that are valid on all platforms.
Differential Revision: https://reviews.llvm.org/D91181
This patch implements 2802. Requires _Deleter to have call operator and be move constructible. Based on D62233.
Refs PR37637.
Differential Revision: https://reviews.llvm.org/D62274
Implements parts of:
- P0898R3 Standard Library Concepts
- P1754 Rename concepts to standard_case for C++20, while we still can
Differential Revision: https://reviews.llvm.org/D96577
The root_path function has to be changed to return the parsed bit
as-is; otherwise a path like "//net" gets a root path of "//net/", as
the root name, "//net", gets the root directory (an empty string) appended,
forming "//net/". (The same doesn't happen for the root dir "c:" though.)
Differential Revision: https://reviews.llvm.org/D91178
Implements parts of:
- P0645 Text Formatting
Depends on D92214
Reland with changes:
The format header will only be compiled if the compiler used has support
for concepts. This should fix the issues with the initial version.
Differential Revision: https://reviews.llvm.org/D93166
Implements parts of:
- P0898R3 Standard Library Concepts
- P1754 Rename concepts to standard_case for C++20, while we still can
Differential Revision: https://reviews.llvm.org/D96235
Implements parts of:
- P0898R3 Standard Library Concepts
- P1754 Rename concepts to standard_case for C++20, while we still can
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D74292
Implements parts of:
* P0898R3 Standard Library Concepts
* P1754 Rename concepts to standard_case for C++20, while we still can
Differential Revision: https://reviews.llvm.org/D88131
Implements parts of:
- P0898R3 Standard Library Concepts
- P1754 Rename concepts to standard_case for C++20, while we still can
Depends on D96230
Differential Revision: https://reviews.llvm.org/D96232
Implements parts of:
- P0898R3 Standard Library Concepts
- P1754 Rename concepts to standard_case for C++20, while we still can
Depends on D77961
Differential Revision: https://reviews.llvm.org/D96230
Implements parts of:
- P0898R3 Standard Library Concepts
- P1754 Rename concepts to standard_case for C++20, while we still can
Differential Revision: https://reviews.llvm.org/D77961
Implement the resolution of LWG2993. Replace a deleted constructor
with a constructor that SFINAEs away in appropriate circumstances.
Also, now that the constructor is templated, we must have an
explicit deduction guide to make CTAD work.
Some tests have been merged in from Agustín Bergé's D40259.
Differential Revision: https://reviews.llvm.org/D92725
Adds `noexcept` to `string_view`/`string::find` and similar members
(`rfind`, etc.). See discussion in D95251. Refs D95821.
Reviewed By: curdeius, ldionne
Differential Revision: https://reviews.llvm.org/D95848
Switch StdTuple printer from python 2-style "next" to python 3.
Nested iteration changed enough to make the original bitset iteration
code a bit trickier than it needs to be, so unnest.
The end node of a map iterator is sometimes hard to detect in isolation,
don't fail in that case.
Differential Revision: https://reviews.llvm.org/D96167
- Quality-of-implementation: Avoid calling __unwrap_iter in constexpr contexts.
The user might conceivably write a contiguous iterator where normal iterator
arithmetic is constexpr-friendly but `std::to_address(it)` isn't.
- Bugfix: When you pass contiguous iterators to `std::copy`, you should get
back your contiguous iterator type, not a raw pointer. That means that
libc++ can't `__unwrap_iter` unless it also does `__rewrap_iter`.
Fortunately, this is implementable.
- Improve test coverage of the new `contiguous_iterator` test iterator.
This catches the bug described above.
- Tests: Stop testing that we can `std::copy` //into// an `input_iterator`.
Our test iterators may currently support that, but it seems nonsensical to me.
Differential Revision: https://reviews.llvm.org/D95983
This reverts commit b6ffece320.
The bug is now fixed (it was a stupid cut-and-paste kind of error),
and the regression test added. The new patch is also simpler than the old one!
Differential Revision: https://reviews.llvm.org/D96084
Before this patch, feature-test macros didn't take special availability
markup into account, which means that feature-test macros can sometimes
appear to "lie". For example, if you compile in C++20 mode and target
macOS 10.13, the __cpp_lib_filesystem feature-test macro will be provided
even though the <filesystem> declarations are marked as unavailable.
This patch fixes that.
rdar://68142369
Differential Revision: https://reviews.llvm.org/D94983
These function makes it easier to write generic unit tests for the
format header. It solves the issue where it's not possible to use
`templated_prefix"foo"`
where `templated_prefix` resolves to: nothing, `L`, `u8`, `u`,
or `U`. The templated_prefix would be more faster during execution.
Reviewed By: ldionne, #libc, curdeius
Differential Revision: https://reviews.llvm.org/D93414
- Implement C++20's changes to `reverse_iterator`, so that it won't be
accidentally counted as a contiguous iterator in C++20 mode.
- Implement C++20's changes to `move_iterator` as well.
- `move_iterator` should not be contiguous. This fixes a bug where
we optimized `std::copy`-of-move-iterators in an observable way.
Add a regression test for that bugfix.
- Add libcxx tests for `__is_cpp17_contiguous_iterator` of all relevant
standard iterator types. Particularly check that vector::iterator
is still considered contiguous in all C++ modes, even C++03.
After this patch, there continues to be no supported way to write your
own iterator type in C++17-and-earlier such that libc++ will consider it
"contiguous"; however, we now fully support the C++20 approach (in C++20
mode only). If you want user-defined contiguous iterators in C++17-and-earlier,
libc++'s position is "please upgrade to C++20."
Differential Revision: https://reviews.llvm.org/D94807
This reverts commit 35a57f39b5.
A build is broken during clang bootstrap with:
In file included from ../libcxx/src/format.cpp:9:
/tmp/ci-nGNyLRM9V3/include/c++/v1/format:153:16: error: no member named 'is_constant_evaluated' in namespace 'std::__1'
if (_VSTD::is_constant_evaluated() && __id >= __num_args_)
~~~~~~~^
1 error generated.
Implements:
- LWG3149 DefaultConstructible should require default initialization
Implements parts of:
- P0898R3 Standard Library Concepts
- P1754 Rename concepts to standard_case for C++20, while we still can
Depends on D91986
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D93461
Add deleted volatile copy-assignment operator in the most derived atomic
to fix the Bug 41784. The root cause: there is an `operator=(T) volatile`
that has better match than the deleted copy-assignment operator of the base
class when `this` is `volatile`. The compiler sees that right operand of
the assignment operator can be converted to `T` and chooses that path
without taking into account the deleted copy-assignment operator of the
base class.
The current behavior on libstdc++ is different from what we have in libc++.
On the same test compilation fails with libstdc++. Proof: https://godbolt.org/z/nebPYd
(everything is the same except the -stdlib option).
I choose the way with explicit definition of copy-assignment for atomic
in the most derived class. But probably we can fix that by moving
`operator=(T)` overloads to the base class from both specializations.
At first glance, it shouldn't break anything.
Differential Revision: https://reviews.llvm.org/D90968
The MS STL does even more cleanup (corresponding to lexically_normal
I think), but this seems to be the very minimum needed for making the
symlinks work when the target path contains non-native paths.
Differential Revision: https://reviews.llvm.org/D91145
... so that comparisons with an `int` LHS and `MoveOnly` RHS are valid, as is necessary for the `partial_sort_copy` test to pass with an implementation that doesn't force a conversion to the type of the RHS as libc++ does.
P1614R2 removes most of `directory_entry`'s member comparison operators, leaving only `operator==` and `operator<=>`. This test should require the comparison expressions to be valid rather than require the member functions to be present so it is correct in both C++17 and C++20 modes.
Implements parts of:
- P0898R3 Standard Library Concepts
- P1754 Rename concepts to standard_case for C++20, while we still can
Depends on: D91004
Reviewed By: ldionne, cjdb, #libc
Differential Revision: https://reviews.llvm.org/D91986
This is the first step at implementing <format>. It adds the <format> header
and implements the `format_error`. class.
Implemnts parts of:
-P0645 Text Formatting
Reviewed By: ldionne, #libc, miscco, curdeius
Differential Revision: https://reviews.llvm.org/D92214
This patch is more than just adding the `constexpr` keyword, because
the old code relied on `goto`, and `goto` is not constexpr-friendly.
Refactor to eliminate `goto`, and then mark it as constexpr in C++20.
I freely admit that the name `__nth_element_partloop` is bad;
I couldn't find any better name because I don't really know
what this loop is doing, conceptually. Vice versa, I think
`__nth_element_find_guard` has a decent name.
Now the only one we're still missing from P0879 is `sort`.
Differential Revision: https://reviews.llvm.org/D93557
LWG reflector consensus is that this was a bug in libc++.
(In particular, MSVC also will fix it in their STL, soon.)
Bug originally discovered by Logan Smith.
Also fix `std::function<const void()>`, which should work
the same way as `std::function<void()>` in terms of allowing
"conversions" from non-void types.
Differential Revision: https://reviews.llvm.org/D94452
After this patch, the only parts of P0879 that remain missing will be
std::nth_element, std::sort, and the heap/partial_sort algorithms.
Differential Revision: https://reviews.llvm.org/D93443
During the review of D91986 it has been discovered the in C++11
deprecated `throw()` exception specification has been removed in
C++20. Removed the part of the test code using this feature.
Implements parts of:
- P0898R3 Standard Library Concepts
- P1754 Rename concepts to standard_case for C++20, while we still can
Reviewed By: ldionne, miscco, #libc
Differential Revision: https://reviews.llvm.org/D91004
Currently all these tests are XFAILED on Linux even though the problem
only seems to be with the few checks that look at collation. To retain
test coverage this splits the locale-dependent tests into a separate
.pass.cpp that is XFAILed as before.
This commit also XFAILs the locale-dependent tests on FreeBSD since the
[=M=] and [.ch.] behaviour for cs_CZ also doesn't seem to match the
behaviour that is expected by these tests.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D94969
Previously, LIBCXX_ENABLE_FILESYSTEM controlled only whether the filesystem
support was compiled into libc++'s library. This commit promotes the
setting to a first-class option like LIBCXX_ENABLE_LOCALIZATION, where
the whole library is aware of the setting and features that depend on
<filesystem> won't be provided at all. The test suite is also properly
annotated such that tests that depend on <filesystem> are disabled when
the library doesn't support it.
This is an alternative to https://llvm.org/D94824, but also an improvement
along the lines of LIBCXX_ENABLE_LOCALIZATION that I had been wanting to
make for a while.
Differential Revision: https://reviews.llvm.org/D94921
When the Debug mode is enabled, we disable extern declarations because we
don't want to use the functions compiled in the library, which might not
have had the debug mode enabled when built. However, some extern declarations
need to be kept, because code correctness depends on it.
31e820378b removed those declarations, which had the unintended
consequence of breaking the debug build. This commit fixes that by
re-introducing a separate macro for the required extern declarations,
and adds a comment so that we don't fall into that trap in the future.
Differential Revision: https://reviews.llvm.org/D94718
Several subprojects have targets that do the same thing, and they all
follow the same naming convention: llvm-test-depends, clang-test-depends,
lld-test-depends, etc.
This makes libc++ consistent with other LLVM projects.
Thanks to Duncan Exon Smith for noticing and suggesting the change.
Differential Revision: https://reviews.llvm.org/D94499
If mutex::try_lock() is called in a thread that already owns the mutex,
the behavior is undefined. The patch fixes the issue by creating another
thread, where the call is allowed.
Differential Revision: https://reviews.llvm.org/D94656
This adds `// clang-format off` in the auto-generated file to avoid lint warnings.
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D94410
I accidentally disabled this feature-test macro in my D93830,
due to a rebasing conflict. It had been enabled by my D93815,
and should have remained enabled.
This patch updates `allocate_shared` to call `allocator_traits::construct`
when creating the object held inside the shared_pointer, and
`allocator_traits::destroy` when destroying it. This resolves
the part of P0674R1 that was originally filed as LWG2070.
This change is landed separately from the rest of P0674R1 because it is
incredibly tricky from an ABI perspective.
This is the reason why this change is so tricky is that we previously
used EBO in a compressed pair to store both the allocator and the object
type stored in the `shared_ptr`. However, starting in C++20, P0674
requires us to use Allocator construction for initializing the object type.
That requirement rules out the use of the EBO for the object type, since
using the EBO implies that the base will be initialized when the control
block is initialized (and hence we can't do it through Allocator construction).
Hence, supporting P0674 requires changing how we store the object type
inside the control block, which we do while being ABI compatible by using
some trickery with a properly aligned char buffer.
Fixes https://llvm.org/PR41900
Supersedes https://llvm.org/D62760
Differential Revision: https://reviews.llvm.org/D91201
It's still a little confusing because in many cases C++17 and C++20
have different values, and libc++ implements the C++17 behavior but
not the C++20 behavior; 'unimplemented' can't represent that scenario.
Ultimately we probably ought to completely redesign the script to be
in terms of paper numbers, rather than language revisions, and make
it generate the CSV files like "Cxx2aStatusPaperStatus.csv" as well.
Most newly added macros are unimplemented. I've marked a few as implemented,
though, based on my reading of the code; for example I was pretty sure
`__cpp_lib_latch` is implemented since we have `<latch>`.
Differential Revision: https://reviews.llvm.org/D93830
FreeBSD did not provide the __atomic_* functions as part of the base
system until recently. They were added to libgcc_s in SVN revision r364753
(August 2020), so check for availability of 'non-lockfree-atomics' so that
these tests do not fail unexpectedly on older versions of FreeBSD.
This also removes the #ifndef __APPLE__ from atomic_helpers.h that was used
to work around lack of atomic runtime functions on older Apple platforms
and replaces it with XFAIL: !non-lockfree-atomics.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D88818
* The only exception is that the flag -std=c++2a is still used not to break compatibility with older compilers (clang <= 9, gcc <= 9).
* Bump _LIBCPP_STD_VER for C++20 to 20 and use 21 for the future standard (C++2b).
That's a preparation step to add c++2b support to libc++.
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D93383
The nullptr_t_integral_cast.pass.cpp test is currently xfailed for
C++03, but actually, it only fails with the first version of libc++
ABI.
This patch changes XFAIL to UNSUPPORTED to avoid unexpected passes
with ABI v2 or later.
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D93941
This affects only vectors with weird/malicious allocators,
the same corner case covered in D91708, but for `vector<bool>` this time.
Also ADL-proof <__tree>, which affects only sets and maps with weird/malicious
allocators where the ADL trap is in the *fancy pointer type*.
Also drive-by _VSTD:: qualification in the guts of std::bind,
std::packaged_task, std::condition_variable.
Differential Revision: https://reviews.llvm.org/D93424
"LLVM Buildbot on libcxx-libcxxabi-x86_64-linux-debian" is not happy
with default-initializing the `double` member of `A` in a constexpr
function. At least I'm pretty sure that's what it's complaining about.
On macOS 10.14 /usr/lib/system/libcompiler_rt.dylib contains all the
`__atomic_load*`, etc. functions but does not include the `__atomic_is_lock_free`
function. The lack of this function causes the non-lockfree-atomics feature
to be set to false even though large atomic operations are actually
supported, it's just the is_lock_free() function that is missing.
This is required so that the !non-lockfree-atomics feature can be used
to XFAIL tests that require runtime library support (D88818).
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D91911
When the allocator is only explicitly convertible from other specializations
of itself, the new version of std::allocate_shared would not work because
it would try to do an implicit conversion. This patch fixes the problem
and adds a test so that we don't fall into the same trap in the future.
Checking that `T` is constructible from `Args...` is technically not
required by the Standard, although any implementation will obviously
error out if that's not satisfied. However, this check is incompatible
with using Allocator construction in the control block (upcoming change
as part of implementing P0674), so I'm removing it now to reduce the
upcoming diff as much as possible.
Differential Revision: https://reviews.llvm.org/D93246
In addition to making the code a lot easier to grasp by localizing many
helper functions to the only file where they are actually needed, this
will allow creating helper functions that depend on allocator_traits
outside of <memory>.
This is done as part of implementing array support in allocate_shared,
which requires non-trivial array initialization algorithms that would be
better to keep out of <memory> for sanity. It's also a first step towards
splitting up our monolithic headers into finer grained ones, which will
make it easier to reuse functionality across the library. For example,
it's just weird that we had to define `addressof` inside <type_traits>
to avoid circular dependencies -- instead it's better to implement those
in true helper headers.
Differential Revision: https://reviews.llvm.org/D93074
- std::reference_wrapper
- std::function
- std::mem_fn
While I'm here, remove _VSTD:: qualification from calls to `declval`
because it takes no arguments and thus isn't susceptible to ADL.
Differential Revision: https://reviews.llvm.org/D92884
Everywhere, normalize the whitespace to `::new (EXPR) T`.
Everywhere, normalize the spelling of the cast to `(void*)EXPR`.
Without the cast to `(void*)`, the expression triggers ADL on GCC.
(I think this is a GCC bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98249)
Even if it doesn't trigger ADL, it still seems incorrect to use any argument
that's not exactly `(void*)` because that opens the possibility of overload
resolution picking a user-defined overload of `operator new`, which would be
wrong.
Differential Revision: https://reviews.llvm.org/D93153
Otherwise they come out in random (inode?) order.
Also `chmod +x` the generator, and re-run it. Somehow on Marek's
machine it produced \r\n line endings?! Open all files with
`newline='\n'` so that (if the Python3 docs are correct)
that won't happen again.
Differential Revision: https://reviews.llvm.org/D93137
This simplifies the implementation, and it appears to be equivalent since
make_shared was allocating memory with std::allocator anyway.
Differential Revision: https://reviews.llvm.org/D93071
Idea from D92525.
This script globs include/ directory and updates the tests in test/libcxx.
This patch does not generate module.modulemap nor CMakeLists.txt.
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D92656
The interesting change here is that we no longer consider `__convert_to_integral`
an ADL customization point for the user's types. I think the new behavior
is defensible. The old behavior had come from D7449, where Marshall explicitly
said "people can't define their own [`__convert_to_integral` overloads]."
Differential Revision: https://reviews.llvm.org/D92814
These had been waiting on the ability to use `std::copy` from
constexpr code (which in turn had been waiting on the ability to
use `is_constant_evaluated()` to switch between `memmove` and non-`memmove`
implementations of `std::copy`). That work landed a while ago,
so these algorithms can all be constexpr in C++20 now.
Simultaneously, update the tests for the set algorithms.
- Use an element type with "equivalent but not identical" values.
- The custom-comparator tests now pass something different from `operator<`.
- Make the constexpr coverage match the non-constexpr coverage.
Differential Revision: https://reviews.llvm.org/D92255
previously, invocations of std::sort(T**, T**) casted the arguments to
(size_t *). this breaks sorting on systems for which pointers don't fit
in a size_t. change the cast to (uintptr_t *) and add a test.
Differential Revision: https://reviews.llvm.org/D92190
It was added in commit 0b71bf7939, "[libcxx] [test] Add a test for conversions between wchar_t, utf8, char16_t, char32_t and windows native narrow code pages"
This implements the std::filesystem parts of P0482 (which is already
marked as in progress), and applies the actions that are suggested
in P1423.
Differential Revision: https://reviews.llvm.org/D90222
Some C++20 headers weren't added properly to all three of these
test files. Add them, and take the time to normalize the formatting
so that
diff <(grep '#include' foo.cpp) <(grep '#include' bar.cpp)
shows no diffs (except that `no_assert_include` deliberately
excludes `<cassert>`).
- Add macro guards to <{barrier,latch,semaphore}>.
- Add macro guards to <experimental/simd>.
- Remove an include of <cassert> from <semaphore>.
- Instead, include <cassert> in the semaphore tests.
Differential Revision: https://reviews.llvm.org/D92525
Since we know exactly which identifiers we expect to find in `chrono`,
a using-directive seems like massive overkill. Remove the directives
and qualify the names as needed.
One subtle trick here: In two places I replaced `*__p` with `*__p.get()`.
The former is an unqualified call to `operator*` on a class type, which
triggers ADL and breaks the new test. The latter is a call to the
built-in `operator*` on pointers, which specifically
does NOT trigger ADL thanks to [over.match.oper]/1.
Differential Revision: https://reviews.llvm.org/D92243
The 5f12f4ff90 commit suppress printing of
inline namespace names in diagnostics by default that breaks the libc++
iterator test, which expects __1 in the namespace.
This patch fixes the test by supporting a test case without __1 in the
namespace.
Differential Revision: https://reviews.llvm.org/D92142
This patch updates algorithms in <numeric> to use std::move
based on p0616r0. Moving values instead of copying them
creates huge speed improvements (see the paper for details).
Differential Revision: https://reviews.llvm.org/D61170
We create threads using std::thread in various places in the test suite.
However, the usual std::thread constructor may not work on all platforms,
e.g. on platforms where passing a stack size is required to create a thread.
This commit introduces a simple indirection that makes it easier to tweak
how threads are created inside the test suite on various platforms. Note
that tests that are purposefully calling std::thread's constructor directly
(e.g. because that is what they're testing) were not modified.
FreeBSD's locale data uses the same U+2027 separator as Glibc 2.27 and newer.
Reviewed By: #libc, emaste, ldionne
Differential Revision: https://reviews.llvm.org/D91165
This will fix remaining failures on gcc-9 buildbot: http://lab.llvm.org:8011/#/builders/101.
gcc-8 and gcc-9 do not support constexpr destructors nor constexpr allocation.
Fix gcc warnings: -Wconversion, -Wpragmas.
This should make the builder http://lab.llvm.org:8011/#/builders/101/ happy.
It uses gcc-9 and not Tip-Of-Trunk as its name indicates BTW.
GCC-10 passes all these tests.
Fix gcc warnings: -Wsign-compare, -Wparentheses, -Wpragmas.
Reviewed By: ldionne, #libc, #libc_abi
Differential Revision: https://reviews.llvm.org/D92099
Implements P1956: On the names of low-level bit manipulation functions.
Users may use older versions of libc++ or other standard libraries with the old names. In order to keep compatibility the old functions are kept, but marked as deprecated.
The patch also adds a new config macro `_LIBCPP_DEPRECATED_MSG`. Do you prefer a this is a separate patch?
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D90551
Zoe Carver says: "We decided that libc++ only supports C++20 constexpr algorithms
when `is_constant_evaluated` is also supported. Here's a link to the discussion."
https://reviews.llvm.org/D65721#inline-735682
Remove _LIBCPP_HAS_NO_BUILTIN_IS_CONSTANT_EVALUATED from tests, too.
See Louis's 5911e6a885 if needed to fix bots.
I've applied `UNSUPPORTED: clang-8` preemptively to the altered tests;
I don't know for sure that this was needed, because no clang-8 buildbots
are triggered on pull requests.
Fixes LWG issue 2724: "The protected virtual member functions of memory_resource should be private."
Differential Revision: https://reviews.llvm.org/D66615
This reverts commit 620adacf87.
Fix: unsupport C++03 for the new test, define helpers before __swap_allocator
(1) Add _VSTD:: qualification to __swap_allocator.
(2) Add _VSTD:: qualification consistently to __to_address.
(3) Add some more missing _VSTD:: to <vector>, with a regression test.
This part is cleanup after d9a4f936d0.
Note that a vector whose allocator actually runs afoul of any of these ADL calls will
likely also run afoul of simple things like `v1 == v2` (which is also an ADL call).
But, still, libc++ should be consistent in qualifying function calls wherever possible.
Relevant blog post: https://quuxplusone.github.io/blog/2019/09/26/uglification-doesnt-stop-adl/
Differential Revision: https://reviews.llvm.org/D91708
(1) Add _VSTD:: qualification to __swap_allocator.
(2) Add _VSTD:: qualification consistently to __to_address.
(3) Add some more missing _VSTD:: to <vector>, with a regression test.
This part is cleanup after d9a4f936d0.
Note that a vector whose allocator actually runs afoul of any of these ADL calls will
likely also run afoul of simple things like `v1 == v2` (which is also an ADL call).
But, still, libc++ should be consistent in qualifying function calls wherever possible.
Relevant blog post: https://quuxplusone.github.io/blog/2019/09/26/uglification-doesnt-stop-adl/
Differential Revision: https://reviews.llvm.org/D91708
These changes cause substantial binary size increases for non-opt builds.
For example, the visit.pass.cpp test grows from 20k to 420k.
Further work will be done to re-land this patch without the size increases,
but that work is proving too tricky to fix forward.
This patch fully reverts:
* 35d2269111
And it partially reverts:
* bb43a0cd4a
The latter of which added XFAIL's to new variant tests
because the new implementation needlessly makes non-throwing code
paths in variant invoke throwing code.
This means the reverted change also breaks source backwards compat
with code compiled on OS X targeting older system dylibs. There is no
need for this to be the case. We should fix it before recommitting.
Reviewed as:
https://reviews.llvm.org/D91662
Also, enable them whenever we detect that gdb is available. Previously,
these tests would basically never run because they relied on a CMake
configuration option that defaulted to OFF.
Differential Revision: https://reviews.llvm.org/D91434
This patch changes how linear_congruential_engine picks its randomization
algorithm. It adds two restrictions, `_OverflowOK` and `_SchrageOK`.
`_OverflowOK` means that m is a power of two so using the classic
`(a * x + c) % m` will create a meaningless overflow. The second checks
that Schrage's algorithm will produce results that are in bounds of min
and max. This patch fixes https://llvm.org/PR27839.
Differential Revision: D65041
Summary:
Before this patch, we could only link against the back-deployment libc++abi
dylib. This patch allows linking against the just-built libc++abi, but
running against the back-deployment one -- just like we do for libc++.
Also, add XFAIL markup to flag expected errors.
The current way we test this is pretty cheap, i.e. we download previously
released macOS dylibs and run against that. Ideally, we would require a
full host running the appropriate version of macOS, and we'd execute the
tests using SSH on that host. But since we don't have such hosts available
easily for now, this is better than nothing.
At the same time, also fix some tests that were failing when back
deploying.
Differential Revision: https://reviews.llvm.org/D90869
This undefined behavior was found by applying Lénárd Szolnoki's proposal
to disable implicit conversion of default_delete<D> to default_delete<B>.
The offending part of the test is circa line 243.
The wording that makes it undefined behavior is http://eel.is/c++draft/expr.delete#3 .
Differential Revision: https://reviews.llvm.org/D90536
Some executors do not run the tests in a shell, and so assuming that
they can understand shell builtins is wrong. Instead, call Bash
directly to do what we need to do.
This still requires the executor to be able to run Bash, but at least
it does not require it to interpret command lines in the Bash language.
Unfortunately, executing these tests correctly on platforms that do not
support a shell is very challenging. Since the executor can't just negate
the result of the command, we'd have to ship a portable program capable
of running the actual test executable, and negating its result.
Doing this portably is challenging. Since we do not currently have strong
use cases for tests that fail at runtime (we effectively have no tests
using that capability right now), it is difficult to justify making them
work portably. Instead, it makes more sense to remove this feature until
we can implement it properly (i.e. without requiring shell support).
error_code returned from functions might not be of the generic category,
but of the system category, which can have different error code values.
Use default_error_condition() to remap errors to the generic category
where possible, to allow comparing them to the expected values.
Use the ErrorIs() helper instead of a direct comparison against
an excpected value.
Differential Revision: https://reviews.llvm.org/D90602
Prepend the root path on the already_absolute testcase, and construct
a path ending with the preferred separator for the test reference for
"foo/".
Differential Revision: https://reviews.llvm.org/D89944
The strings were concatenated together without adding spaces between
numbers, which lead to numbers that wouldn't fit in an unsigned int.
Thanks to Casey Carter for the find.
- Several -Wshadow warnings
- Several places where we did not initialize our base class explicitly
- Unused variable warnings
- Some tautological comparisons
- Some places where we'd pass null arguments to functions expecting
non-null (in unevaluated contexts)
- Add a few pragmas to turn off spurious warnings
- Fix warnings about declarations that don't declare anything
- Properly disable deprecation warnings in ext/ tests (the pragmas we
were using didn't work on GCC)
- Disable include_as_c.sh.cpp because GCC complains about C++ flags
when compiling as C. I couldn't find a way to fix this one properly,
so I'm disabling the test. This isn't great, but at least we'll be
able to enable warnings in the whole test suite with GCC.
This will allow adding bare compiler flags through the new
configuration DSL. Previously, this would have required adding
a Lit feature for each such flag.
Differential Revision: https://reviews.llvm.org/D90429
The explicit call to `std::setlocale(LC_ALL, "C")` isn't required, since
the Standard already says the equivalent of this call is performed on
program startup.
On windows, the previous path replacement using forward slashes wouldn't
work, and so we'd end up including the same file again. We would do that
until we'd hit the recursion limit of the Python interpreter.
Instead, use `os.path` to properly replace without assuming a specific
path separator.
When porting libc++ to embedded systems, it can be useful to drop support
for localization, which these systems don't implement or care about.
Differential Revision: https://reviews.llvm.org/D90072
The variable declarations interleaved with logic was really difficult
to read. Instead, simply have two different implementations for _WIN32
and others.
This is a massive revert of the following commits (from most revent to oldest):
2b9b7b5775.
529ac3319728270234f169c2087283b5aa67446e5d796645d6
After checking-in the __config_site change, a lot of things started breaking
due to widespread reliance on various aspects of libc++'s build, notably the
fact that we can include the headers from the source tree, but also reliance
on various "internal" CMake variables used by the runtimes build and compiler-rt.
These were unintended consequences of the change, and after two days, we
still haven't restored all the bots to being green. Instead, now that I
understand what specific areas this will blow up in, I should be able to
chop up the patch into smaller ones that are easier to digest.
See https://reviews.llvm.org/D89041 for more details on this adventure.
The individual enum values in copy_options and file_type aren't
specified in the standard.
The standard doesn't require fs::path::format to be a scoped enum.
Differential Revision: https://reviews.llvm.org/D89866
Prior to this patch, we would generate a fancy <__config> header by
concatenating <__config_site> and <__config>. This complexifies the
build system and also increases the difference between what's tested
and what's actually installed.
This patch removes that complexity and instead simply installs <__config_site>
alongside the libc++ headers. <__config_site> is then included by <__config>,
which is much simpler. Doing this also opens the door to having different
<__config_site> headers depending on the target, which was impossible before.
It does change the workflow for testing header-only changes to libc++.
Previously, we would run `lit` against the headers in libcxx/include.
After this patch, we run it against a fake installation root of the
headers (containing a proper <__config_site> header). This makes use
closer to testing what we actually install, which is good, however it
does mean that we have to update that root before testing header changes.
Thus, we now need to run `ninja check-cxx-deps` before running `lit` by
hand.
This commit was originally applied in 1e46d1aa3 and reverted in eb60c487
because it broke the libc++abi and libunwind test suites. This has now
been fixed.
Differential Revision: https://reviews.llvm.org/D89041
Prior to this patch, we would generate a fancy <__config> header by
concatenating <__config_site> and <__config>. This complexifies the
build system and also increases the difference between what's tested
and what's actually installed.
This patch removes that complexity and instead simply installs <__config_site>
alongside the libc++ headers. <__config_site> is then included by <__config>,
which is much simpler. Doing this also opens the door to having different
<__config_site> headers depending on the target, which was impossible before.
It does change the workflow for testing header-only changes to libc++.
Previously, we would run `lit` against the headers in libcxx/include.
After this patch, we run it against a fake installation root of the
headers (containing a proper <__config_site> header). This makes use
closer to testing what we actually install, which is good, however it
does mean that we have to update that root before testing header changes.
Thus, we now need to run `ninja check-cxx-deps` before running `lit` by
hand.
Differential Revision: https://reviews.llvm.org/D89041
Split the resolution check to a separate test, which is marked as
unsupported on windows.
On windows (both with MS STL and libstdc++), the file time has
100 ns resolution; the standard doesn't mandate a specific resolution.
Differential Revision: https://reviews.llvm.org/D89535
Use p.string() instead of p.native() for comparing with the expected
value.
Explicitly list the expected values for both posix and windos, even if
the operation is an identity operation on posix.
Differential Revision: https://reviews.llvm.org/D89532
This is defined both by libcxx/utils/libcxx/test/config.py (for
any windows target) and msvc_stdlib_force_include.h (when testing
specifically the MSVC C++ library).
The command line define (-D_CRT_SECURE_NO_WARNINGS) defines it to the
value 1; change the header define to match that.
Keeping both instances, to keep the fix for cases when not building
in cases that don't use config.py.
Also remove a comment about whether this can be removed; it can't at
least be removed altogether - doing that breaks a number of tests that
otherwise succeed.
Differential Revision: https://reviews.llvm.org/D89588
Use `__FUNCSIG__` instead when compiling with MSVC. While we're touching `makeTypeIDImp`, remove the warning suppression for C4640 "construction of local static object is not thread safe" since C1XX now correctly constant-initializes `id`.
The Standard doesn't include the
```c++
template<class T>
T* atomic_fetch_meow(atomic<T*>, ...);
```
templates these tests are testing.
(See https://bugs.llvm.org/show_bug.cgi?id=47908)
Use fs::path as variable type instead of std::string, when the input
potentially is a path, as they can't be implicitly converted back to
string.
Differential Revision: https://reviews.llvm.org/D89674
Use .string() instead of .native() in places where we want to combine
paths with std::string.
Convert some methods to take a fs::path as parameter instead of
std::string, for cases where they are called with paths as
parameters (which can't be implicitly converted to std::string if
the path's string_type is wstring).
Differential Revision: https://reviews.llvm.org/D89530
Mark this as a libcpp specific test; the standard doesn't say that
this method should be noexcept.
Differential Revision: https://reviews.llvm.org/D89677
The standard doesn't declare this overload as noexcept, but doesn't
either say that it strictly cannot be noexcept either. The function
doesn't throw on errors that are signaled via error_code, but the
standard says that it may throw a bad_alloc.
This fixes an error with libstdc++ on linux.
Differential Revision: https://reviews.llvm.org/D89678
This makes them more readable in llvm-lit's output on failures.
This only applies the change on the filesystem test subdir.
Differential Revision: https://reviews.llvm.org/D89680
It appears that the released version of clang that supports constexpr
destructors is clang 10 and the oldest one that accepts -std=c++2a is 5,
so mark these as UNSUPPORTED for clang-5 to clang-9.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D89704
Define all the fuzzing tests in libcxx/test/libcxx/fuzzing, and get
rid of the ad-hoc libcxx/fuzzing directory, which wasn't properly
integrated with the build system or test suite.
As a fly-by change, this also reduces the dependencies of fuzzing tests
on large library components like <iostream>, to make them work on more
platforms.
This changes the checking for available locales to use one program that
iterates over argv to test multiple locale names instead of checking each
name with a separate executable.
This massively speeds up running individual tests using an SSH executor
(it can take up to 10 seconds to compile and run a single test in some
emulated environments) in case no locales are installed since then all
fallback names are tested idividually. But even on a native machine
this reduces the libc++ lit startup time by ~1-2 second for me on a machine
that does not have locale data installed.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D88884
On FreeBSD we get the following error when passing zero as the requested
alignment: error: requested alignment is not a power of 2
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D88820
Use string() for convenience for testing where possible, but keep using
native() for move tests where we want to check that no allocations are
made, constructing a reference fs::path::string_type instead.
Use the right value_type in a few places.
Make the synop test check for the right types and for the expected
preferred separator.
Differential Revision: https://reviews.llvm.org/D89537
Instead of having this script be part of the OSS-Fuzz repository, I think
it makes more sense to have it alongside the rest of the fuzzing targets
in libc++.
This fixes building with libstdc++ for windows. MS STL has got
ifstream/ofstream overloads that taken wide strings though.
Differential Revision: https://reviews.llvm.org/D89539
rGcc69d211d0d65d7b introduced several uses of `printf` with format
directives `%lu` and `%ld` to format values of type `size_t` and
`ptrdiff_t` respectively.
That doesn't reliably work in all C implementations, because those
types aren't necessarily the same thing as 'long int': sometimes
they're not even the same size, and when they are the same size, they
might be officially defined as int rather than long (for example),
which causes clang to emit a diagnostic for the mismatch.
C has special-purpose printf modifier letters for these two types, so
it's safer to use them. Changed all `%lu` on `size_t` to `%zu`, and
all `%ld` on `ptrdiff_t` to `%td`.
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D89545
Some platforms, like several embedded platforms, do not provide a source
of randomness through a random device. This commit makes it possible to
build and test libc++ for such platforms, i.e. without std::random_device.
Surprisingly, the only functionality that doesn't work on such platforms
is std::random_device itself -- everything else in <random> still works,
one just has to find alternative ways to seed the PRNGs.
Also, some tests had multiple death tests in them, so split them into
separate tests instead. The second death test would obviously never
get run, because the first one would kill the program before.
While this adds some convenience to the test suite, it prevents the tests
using these checkpoints from being used on systems where signals are not
available, such as some embedded systems. It will also prevent these tests
from being constexpr-friendly once e.g. std::map is made constexpr, due
to the use of statics.
Instead, one can always use a debugger to figure out exactly where a
test is failing when that isn't clear from the log output without
checkpoints.
We used <iostream> in several places where we don't actually need the
full power of <iostream>, and where using basic `std::printf` is enough.
This is better, since `std::printf` can be supported on systems that don't
have a notion of locales, while <iostream> can't.
To make it clearer this is about whether the library supports the debug
mode at all, not whether the debug mode is enabled. Per comment by Nico
Weber on IRC.
To make sure we don't store a mutable object (which could be modified by
outside code without us noticing) as the cache key, we pickle the cache
key to get a byte stream. If two keys are unequal, we know for sure they
will not have the same pickling. And if they are equal, there's a large
chance they will have the same pickling. If they don't, we might end up
not reusing a cached entry when we could have, but at least the behavior
we'll have is semantically correct.
This is needed when running the tests in Freestanding mode, where main()
isn't treated specially. In Freestanding, main() doesn't get mangled as
extern "C", so whatever runtime we're using fails to find the entry point.
One way to solve this problem is to define a symbol alias from __Z4mainiPPc
to _main, however this requires all definitions of main() to have the same
mangling. Hence this commit.
glibc supports versioning, so it's possible to build against older
version and run against newer version. This is sometimes relied on
in practice, e.g. in Fuchsia build we build against older sysroot
(equivalent to Ubuntu Trusty) to cover the broadest possible range
of host systems, but that doesn't necessarily match the system that
binary is going to run on which may have newer version, in which case
the compile test used in curr_symbol is going to fail. Using runtime
check is more reliable. This is a follow up to D56702 which addressed
one instance, this patch addresses all of the remaining ones.
Differential Revision: https://reviews.llvm.org/D88188
Some libc++ builds may want to disable support for the debug mode,
for example to reduce code size or because the current implementation
of the debug mode requires a global map. This commit adds the
LIBCXX_ENABLE_DEBUG_MODE CMake option and ties it into the test
suite.
It also adds a CI job to test this configuration going forward.
Differential Revision: https://reviews.llvm.org/D88923
These tests were only being run when _LIBCPP_DEBUG was defined, which
isn't the case by default when we run the test suite. In other words,
all these debug mode tests were never being run. This commit makes sure
they are run, and in some cases, extracts them into a file under test/libcxx
to separate them from the Standard tests.
Differential Revision: https://reviews.llvm.org/D88836
* Use an empty struct instead of a member pointer to represent this
type, so that we don't actually pass a zero member pointer at runtime.
* Mark the constructor as consteval to ensure that no code is emitted
for it whenever possible.
* Add a honeypot constructor to reject all non-int arguments, so that
the only argument that can arrive at the real constructor is the
literal 0.
This results in better generated code, and rejecting invalid comparisons
against nullptr, 0L, and so on, while also rejecting invalid comparisons
against (1-1) and similar that would be allowed if we required an
integer constant expression with value 0.
Differential Revision: https://reviews.llvm.org/D85051
After rebasing my trivially-relocatable branch, this behavior was broken...
but no libc++ unit test caught it! Add a regression test specifically for
erasing out of a vector.
Differential Revision: https://reviews.llvm.org/D88421
We're technically not allowed by the Standard to call ::operator new in
constexpr functions like __libcpp_allocate. Clang doesn't seem to complain
about it, but GCC does.
Martin Storsjö