Since we officially don't support several older compilers now, we can
drop a lot of the markup in the test suite. This helps keep the test
suite simple and makes sure that UNSUPPORTED annotations don't rot.
This is the first patch of a series that will remove annotations for
compilers that are now unsupported.
Differential Revision: https://reviews.llvm.org/D107787
This is a workaround until https://reviews.llvm.org/D81892 is merged
and the internal Lit shell stops conflating error output with normal
output. Without this, any program that writes to stderr will trip up
the programOutput function, because it will pick up the '# command stderr:'
string and think it's part of the command's stdout.
rdar://81056048
Differential Revision: https://reviews.llvm.org/D107912
All supported compilers implement __builtin_addressof. Even MSVC implements
addressof as a simple call to __builtin_addressof, so it would work if we
were to port libc++ to that compiler.
Differential Revision: https://reviews.llvm.org/D107905
efriedma noted that D104682 broke this test case, reduced from SPEC2006.
#include <istream>
bool a(std::istream a) {
return a.getline(0,0) == 0;
}
We can unbreak it by restoring the conversion to something-convertible-to-bool.
We chose `void*` in order to match libstdc++.
For more ancient history, see PR19460: https://bugs.llvm.org/show_bug.cgi?id=19460
Differential Revision: https://reviews.llvm.org/D107663
All supported compilers have implemented __has_unique_object_representations
for a while, so it's reasonable to remove the workaround.
Differential Revision: https://reviews.llvm.org/D107834
All supported compilers have been supporting __is_aggregate for a long
time now, so it's reasonable to remove this workaround.
Differential Revision: https://reviews.llvm.org/D107833
All supported compilers should support
_LIBCPP_HAS_NO_BUILTIN_IS_CONSTANT_EVALUATED so this can be removed.
Reviewed By: ldionne, #libc, Quuxplusone
Differential Revision: https://reviews.llvm.org/D107239
This one already had a proper explanation why it fails, which is due to
differences by design in MSVC mode. This isn't a fixme, so degrade the
annotation to a more permanent "XFAIL: msvc" instead.
Differential Revision: https://reviews.llvm.org/D107758
Such environments do have aligned allocation functions these days, but
the RTTI type name test needs to be adjusted for the MSVC C++ ABI.
Differential Revision: https://reviews.llvm.org/D107757
This allows waiving the right amount of asserts on Windows and zOS.
This should supersede D107124 and D105910.
Differential Revision: https://reviews.llvm.org/D107755
This patch fixes the constrains on the __perfect_forward constructor
and its call operators, which were incorrect. In particular, it makes
sure that we closely follow [func.require], which basically says that
we must deliver the bound arguments with the appropriate value category
or make the call ill-formed, but not silently fall back to using a
different value category.
As a fly-by, this patch also:
- Adds types __bind_front_t and __not_fn_t to make the result of
calling bind_front and not_fn more opaque, and improve diagnostics
for users.
- Adds a bunch of tests for bind_front and remove some that are now
redundant.
- Adds some missing _LIBCPP_HIDE_FROM_ABI annotations.
Immense thanks to @tcanens for raising awareness about this issue, and
providing help with the = delete bits.
Differential Revision: https://reviews.llvm.org/D107199
Also, improve tests for std::destroy and std::destroy_n so that they
check for array support.
These changes are part of http://wg21.link/p0896 (the One Ranges proposal).
Differential Revision: https://reviews.llvm.org/D106916
Summary:
Currently, if we pass in the same iterator for begin and end,
the long double version of do_get would throw a runtime error.
However, according to standard (https://eel.is/c++draft/locale.money.get#virtuals-1),
we should set the failbit and eofbit when no more characters are available.
Differential Revision: https://reviews.llvm.org/D100510
Implement the changes in all language modes.
LWG3506 "Missing allocator-extended constructors for priority_queue"
makes the following changes:
- New allocator-extended constructors for priority_queue.
- New deduction guides targeting those constructors.
LWG3522: "Missing requirement on InputIterator template parameter
for priority_queue constructors". The iterator parameter should be
constrained to actually be an iterator type. `priority_queue{1,2}`
should be SFINAE-friendly ill-formed.
Also, do a drive-by fix in the allocator-extended move constructor:
there's no need to do a `make_heap` after moving from `__q.c` into
our own `c`, because that container was already heapified when it
was part of `__q`. [priqueue.cons.alloc] actually specifies the
behavior and does *not* mention calling `make_heap`. I think this
was just a copy-paste thinko. It dates back to the initial import
of libc++.
Differential Revision: https://reviews.llvm.org/D106824
Differential Revision: https://reviews.llvm.org/D106827
This started breaking in the CI because we bumped the Clang version to 14,
which requires adjusting the markup in the test suite. I think it's actually
nice the we need to do that and that it doesn't happen automatically, since
it serves as a reminder that this is broken in Clang.
Adds a new CMake option to disable the usage of incomplete headers.
These incomplete headers are not guaranteed to be ABI stable. This
option is intended to be used by vendors so they can avoid their users
from code that's not ready for production usage.
The option is enabled by default.
Differential Revision: https://reviews.llvm.org/D106763
See LWG reflector thread of 2021-07-23 titled
'Question on ranges::advance and "past-the-sentinel iterators"'.
Test case heavily based on one graciously provided by Casey Carter.
Differential Revision: https://reviews.llvm.org/D106735
Move the tests to libcxx so they no longer need `REQUIRES: libc++`.
Verify tests don't need `REQUIRES: libc++`.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D106673
This started as fixing a typo in a ADDITIONAL_COMPILE_FLAGS directive
which turned out to uncover a few places where we warned about signedness
changes.
As a fly-by fix, this updates the various __advance overloads
for style consistency.
Differential Revision: https://reviews.llvm.org/D106372
`__function_like` wasn't being exported, so certain properties of the
`ranges` functions weren't being propagated in modules land.
Differential Revision: https://reviews.llvm.org/D105078
libc++ has started splicing standard library headers into much more
fine-grained content for maintainability. It's very likely that outdated
and naive tooling (some of which is outside of LLVM's scope) will
suggest users include things such as `<__algorithm/find.h>` instead of
`<algorithm>`, and Hyrum's law suggests that users will eventually begin
to rely on this without the help of tooling. As such, this commit
intends to protect users from themselves, by making it a hard error for
anyone outside of the standard library to include libc++ detail headers.
This is the first of four patches. Patch #2 will solve the problem for
pre-processor `#include`s; patches #3 and #4 will solve the problem for
`<__tree>` and `<__hash_table>` (since I've never touched the test cases
that are failing for these two, I want to split them out into their own
commits to be extra careful). Patch #5 will concern itself with
`<__threading_support>`, which intersects with libcxxabi (which I know
even less about).
Differential Revision: https://reviews.llvm.org/D105932
The checks within the libc++experimental memory_resource class uses this
limit:
_MaxAlign = _LIBCPP_ALIGNOF(max_align_t);
Therefore, only use max_align_t for this limit instead of using
`__STDCPP_DEFAULT_NEW_ALIGNMENT__` if available.
Differential Revision: https://reviews.llvm.org/D105905
* <__algorithm/iter_swap.h>
* <__algorithm/swap_ranges.h>
* <__functional/is_transparent.h>
* <__memory/uses_allocator.h>
* <__ranges/drop_view.h>
* <__ranges/transform_view.h>
* <shared_mutex>
* <span>
Also updates header inclusions that were affected.
**NOTE:** This is a proper subset of D105932. Since the content has
already been LGTM'd, I intend to merge this patch without review,
pending green CI. I decided it would be better to move these changes
into their own commit since the former patch has undergone further
changes and will need yet another light review. In the event any of
that gets rolled back (for whatever reason), the changes in this patch
won't be affected.
Differential Revision: https://reviews.llvm.org/D106040
Instead of using TARGET_TRIPLE, which is always set to LLVM_DEFAULT_TARGET_TRIPLE,
use that variable directly to populate the various XXXX_TARGET_TRIPLE
variables in the runtimes.
This re-applies 77396bbc98 and 5099e01568, which were reverted in
850b57c5fb because they broke the build.
Differential Revision: https://reviews.llvm.org/D106009
This configuration is interesting because GCC has a different level of
strictness for some C++ rules. In particular, it implements the older
standards more stringently than Clang, which can help find places where
we are non-conforming (especially in the test suite).
Differential Revision: https://reviews.llvm.org/D105936
The XFAIL comments about VCRuntime not providing aligned operator new
are outdated; these days VCRuntime does provide them.
However, the tests used to fail on Windows, as the pointers allocated
with an aligned operator new (which is implemented with _aligned_malloc
on Windows) can't be freed using std::free() on Windows (but they need
to be freed with the corresponding function _aligned_free instead).
Instead override the aligned operator new to return a dummy suitably
aligned pointer instead, like other tests that override aligned operator
new.
Also override `operator delete[]` instead of plain `operator delete`
in the array testcase; the fallback from `operator delete[]` to
user defined `operator delete` doesn't work in all DLL build
configurations on Windows.
Also expand the TEST_NOEXCEPT macros, as these tests only are built
in C++17 mode.
By providing the aligned operator new within the tests, this also makes
these test cases pass when testing back deployment on macOS 10.9.
Differential Revision: https://reviews.llvm.org/D105962
add_lit_testsuite() takes Lit parameters passed to it and adds them
to the parameters used globally when running all test suites. That
means that a target like `check-all`, which ends up calling Lit on
the whole monorepo, will see the test parameters for all the individual
project's test suites.
So, for example, it would see `--param std=c++03` (from libc++abi), and
`--param std=c++03` (from libc++), and `--param whatever` (from another
project being tested at the same time). While always unclean, that works
when the parameters all agree. However, if the parameters share the same
name but have different values, only one of those two values will be used
and it will be incredibly confusing to understand why one of the test
suites is being run with the incorrect parameter value.
For that reason, this commit moves away from using add_lit_testsuite()'s
PARAM functionality, and serializes the parameter values for the runtimes
in the generated config.py file instead, which is local to the specific
test suite.
Differential Revision: https://reviews.llvm.org/D105991
It turns out that D105040 broke `std::rel_ops`; we actually do need
both a one-template-parameter and a two-template-parameter version of
all the comparison operators, because if we have only the heterogeneous
two-parameter version, then `x > x` is ambiguous:
template<class T, class U> int f(S<T>, S<U>) { return 1; }
template<class T> int f(T, T) { return 2; } // rel_ops
S<int> s; f(s,s); // ambiguous between #1 and #2
Adding the one-template-parameter version fixes the ambiguity:
template<class T, class U> int f(S<T>, S<U>) { return 1; }
template<class T> int f(T, T) { return 2; } // rel_ops
template<class T> int f(S<T>, S<T>) { return 3; }
S<int> s; f(s,s); // #3 beats both #1 and #2
We have the same problem with `reverse_iterator` as with `__wrap_iter`.
But so do libstdc++ and Microsoft, so we're not going to worry about it.
Differential Revision: https://reviews.llvm.org/D105894
This commit reverts 5099e01568 and 77396bbc98, which broke the build
in various ways. I'm reverting until I can investigate, since that
change appears to be way more subtle than it seemed.
On Windows, structs with a destructor are always returned indirectly;
add this to the list of known exceptions in the test where the class
isn't returned in registers as expected.
Differential Revision: https://reviews.llvm.org/D105906
std::exchange is only constexpr in C++20 and later. We were using it
in a constructor marked unconditionally constexpr, which caused issues
when building with -std=c++17.
The weird part is that the issue only showed up when building on the
arm64 macs, but that must be caused by the specific version of Clang
used on those. Since the code is clearly wrong and the fix is obvious,
I'm not going to investigate this further.
Make sure that the detached thread has started up before exiting
the process.
This is exactly the same fix as D105592, with the same pattern
being present in a different test case.
Differential Revision: https://reviews.llvm.org/D105736
The unit tests test some implementation details. As @Quuxplusone pointed
out in D96664 this should only be tested when the tests use libc++. This
addresses the issue for code already in main.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D105568
Make sure that the detached thread has started up before exiting
the process.
If the detached thread hasn't started up at all, and the main thread
exits, global data structures in the process are torn down, which
then can cause crashes when the thread starts up late after required
mutexes have been destroyed. (In particular, the mutex used internally
in _Init_thread_header, which is used in the initialization of
__thread_local_data()::__p, can cause crashes if the main thread already
has finished and progressed far with destruction.)
Differential Revision: https://reviews.llvm.org/D105592
This is necessary for from-scratch configurations to support the 32-bit
mode of the test suite.
Differential Revision: https://reviews.llvm.org/D105435
Now that Lit supports regular expressions inside XFAIL & friends, it is
much easier to write Lit annotations based on the triple.
Differential Revision: https://reviews.llvm.org/D104747
This is required to run the tests under any configuration that uses
additional_features using a from-scratch config. That is the case of
e.g. the Debug mode (which uses LIBCXX-DEBUG-FIXME) and the tests on
Windows.
While we can debate on the value of passing by const value, there is no
arguing that it's confusing to do so in some circumstances, such as when
marking a pointer parameter as being const (did you mean a pointer-to-const?).
This commit fixes a few issues along those lines.
Before this patch, Lit parameters that were set as a result of CMake
options were not made available to from-scratch configs. This patch
serializes those parameters into the generated lit config file so that
they are available to all configs.
Differential Revision: https://reviews.llvm.org/D105047
This patch is to fix 2 libcxx test cases, test cases assumed 'a' > 'A' which is not case in z/OS platform on ebcdic mode, modified test cases to compare between upper letters or lower letters, or digits so ordering will be true for all platform.
Differential Revision: https://reviews.llvm.org/D104748
With the STL containers, I didn't enable move operations in C++03 mode
because that would change the overload resolution for things that today
are copy operations. With iostreams, though, the copy operations aren't
present at all, and so I see no problem with enabling move operations
even in (Clang's greatly extended) C++03 mode.
Clang's C++03 mode does not support delegating constructors.
Differential Revision: https://reviews.llvm.org/D104310
Moves:
* `std::move`, `std::forward`, `std::declval`, and `std::swap` into
`__utility/${FUNCTION_NAME}`.
* `std::swap_ranges` and `std::iter_swap` into
`__algorithm/${FUNCTION_NAME}`
Differential Revision: https://reviews.llvm.org/D103734
Since we now have modules-enabled CI, it is now redundant to have ad-hoc
tests that check arbitrary things about our modules support. Instead,
the whole test suite should pass with modules enabled, period.
This patch also removes the module cache path workaround: one would
expect that modules work properly without that workaround. If that
isn't the case and we do run into flaky test failures, we can re-enable
the workaround temporarily (but that would be very vexing and we should
fix Clang ASAP if that's the case).
Differential Revision: https://reviews.llvm.org/D104746
zoecarver