The testing script used to test libc++ historically did not like directories
without any testing files, so these tests had been added. Since this is
not necessary anymore, we can now remove these files. This has the benefit
that the total number of tests reflects the real number of tests more
closely, and we also skip some unnecessary work (especially relevant when
running tests over SSH).
However, some nothing_to_do.pass.cpp tests actually serve the purpose of
documenting that an area of the Standard doesn't need to be tested, or is
tested elsewhere. These files are not removed by this commit.
Removal done with:
import os
import itertools
for (dirpath, dirnames, filenames) in itertools.chain(os.walk('./libcxx/test'),
os.walk('./libcxxabi/test')):
if len(filenames + dirnames) > 1 and \
any(p == 'nothing_to_do.pass.cpp' for p in filenames):
os.remove(os.path.join(dirpath, 'nothing_to_do.pass.cpp'))
lit is not very clever when it performs substitution on RUN lines. It
simply looks for a match anywhere in the line (without tokenization)
and replaces it by the expansion. This means that a RUN line containing
e.g. `-verify-ignore-unexpected=note` wouod be expanded to
`-verify-ignore-unexpected=<substitution for not>e`, which is
surprising and nonsensical.
It also means that something like `%compile_module` could be expanded
to `<substitution-for-%compile>_module` or to the correct substitution,
depending on the order in which substitutions are evaluated by lit.
To avoid such problems, it is a good habit to delimit custom substitutions
with some token. This commit does that for all substitutions used in the
libc++ and libc++abi test suites.
Forcing -Werror and other warnings means that the test suite isn't
actually testing what most people are seeing in their code -- it seems
better and less arbitrary to compile these tests as close as possible
to the compiler default instead.
Removing -Werror also means that we get to differentiate between
diagnostics that are errors and those that are warnings, which makes
the test suite more precise.
Differential Revision: https://reviews.llvm.org/D76311
Some tests do not fail at all when -verify is not supported, unless some
arbitrary warning flag is added to make them fail. We currently used
-Werror=unused-result to make them fail, but doing so makes the test
suite a lot more inscrutable. It seems better to just disable those
tests when -verify is not supported.
Differential Revision: https://reviews.llvm.org/D76256
The static asserts in span<T, N>::front() and span<T, N>::back() are
incorrect as they may be triggered from valid code due to evaluation
of a never taken branch:
span<int, 0> foo;
if (!foo.empty()) {
auto x = foo.front();
}
The problem is that the branch is always evaluated by the compiler,
creating invalid compile errors for span<T, 0>.
Thanks to Michael Schellenberger Costa for the patch.
Differential Revision: https://reviews.llvm.org/D71995
The calculation _Offset + _Count <= size() may overflow, so use
_Count <= size() - _Offset instead. Note that this is safe due to
the previous constraint that _Offset <= size().
Patch by Michael Schellenberger Costa.
Differential Revision: https://reviews.llvm.org/D71998
The extent of the returned span was always std::dynamic_extent, which
is incorrect.
Thanks to Michael Schellenberger Costa for the patch.
Differential Revision: https://reviews.llvm.org/D71997
Both methods have compile time constraints that we should test against.
Patch by Michael Schellenberger Costa
Differential Revision: https://reviews.llvm.org/D71999
Summary:
This patch implements https://wg21.link/P0325.
Please mind that at it is my first contribution to libc++, so I may have forgotten to abide to some conventions.
Reviewers: EricWF, mclow.lists, ldionne, lichray
Reviewed By: ldionne, lichray
Subscribers: lichray, dexonsmith, zoecarver, christof, ldionne, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D69882
span.cons/container.pass.cpp
N4842 22.7.3.2 [span.cons]/13 constrains span's range constructor
for ranges::contiguous_range (among other criteria).
24.4.5 [range.refinements]/2 says that contiguous_range requires data(),
and (via contiguous_range, random_access_range, bidirectional_range,
forward_range, input_range, range) it also requires begin() and end()
(see 24.4.2 [range.range]/1).
Therefore, IsAContainer needs to provide begin() and end().
(Detected by MSVC's concept-constrained implementation.)
span.cons/stdarray.pass.cpp
This test uses std::array, so it must include <array>.
<span> isn't guaranteed to drag in <array>.
(Detected by MSVC's implementation which uses a forward declaration to
avoid dragging in <array>, for increased compiler throughput.)
span.objectrep/as_bytes.pass.cpp
span.objectrep/as_writable_bytes.pass.cpp
Testing `sp.extent == std::dynamic_extent` triggers MSVC warning
C4127 "conditional expression is constant". Using `if constexpr` is a
simple way to avoid this without disrupting anyone else (as span
requires C++20 mode).
span.tuple/get.pass.cpp
22.7.3.2 [span.cons]/4.3: "Preconditions: If extent is not equal to
dynamic_extent, then count is equal to extent."
These lines were triggering undefined behavior (detected by assertions
in MSVC's implementation).
I changed the count arguments in the first two chunks, followed by
changing the span extents, in order to preserve the test's coverage
and follow the existing pattern.
span.cons/span.pass.cpp
22.7.3.2 [span.cons]/18.1 constrains span's converting constructor with
"Extent == dynamic_extent || Extent == OtherExtent is true".
This means that converting from dynamic extent to static extent is
not allowed. (Other constructors tested elsewhere, like
span(It first, size_type count), can be used to write such code.)
As this is the test for the converting constructor, I have:
* Removed the "dynamic -> static" case from checkCV(), which is
comprehensive.
* Changed the initialization of std::span<T, 0> s1{}; in
testConstexprSpan() and testRuntimeSpan(), because s1 is used below.
* Removed ASSERT_NOEXCEPT(std::span<T, 0>{s0}); from those functions,
as they are otherwise comprehensive.
* Deleted testConversionSpan() entirely. Note that this could never
compile (it had a bool return type, but forgot to say `return`). And it
couldn't have provided useful coverage, as the /18.2 constraint
"OtherElementType(*)[] is convertible to ElementType(*)[]"
permits only cv-qualifications, which are already tested by checkCV().
libcxx/test/std/containers/sequences/array/at.pass.cpp
Need to include <stdexcept> for std::out_of_range.
libcxx/test/std/localization/locale.categories/category.time/*
Need to include <ios> for std::ios.
[libcxx] [test] Calling min and max on an empty valarray is UB.
libcxx/test/std/numerics/numarray/template.valarray/valarray.members/min.pass.cpp
libcxx/test/std/numerics/numarray/template.valarray/valarray.members/max.pass.cpp
The calls `v1.min();` and `v1.max();` were emitting nodiscard warnings
with MSVC's STL. Upon closer inspection, these calls were triggering
undefined behavior. N4842 [valarray.members] says:
"T min() const;
8 Preconditions: size() > 0 is true.
T max() const;
10 Preconditions: size() > 0 is true."
As these tests already provide coverage for non-empty valarrays
(immediately above), I've simply deleted the code for empty valarrays.
[libcxx] [test] Add macros to msvc_stdlib_force_include.h (NFC).
libcxx/test/support/msvc_stdlib_force_include.h
These macros are being used by:
libcxx/test/std/utilities/meta/meta.trans/meta.trans.other/result_of11.pass.cpp
Defining them to nothing allows that test to pass.
[libcxx] [test] Silence MSVC warning C5063 for is_constant_evaluated (NFC).
libcxx/test/std/utilities/meta/meta.const.eval/is_constant_evaluated.pass.cpp
This test is intentionally writing code that MSVC intentionally warns
about, so the warning should be silenced.
Additionally, comment an endif for clarity.
[libcxx] [test] Silence MSVC warning C4127 (NFC).
libcxx/test/support/charconv_test_helpers.h
MSVC avoids emitting this warning when it sees a single constexpr value
being tested, but this condition is a mix of compile-time and run-time.
Using push-disable-pop is the least intrusive way to silence this.
[libcxx] [test] Silence MSVC truncation warning (NFC).
libcxx/test/std/containers/sequences/vector/vector.cons/construct_iter_iter.pass.cpp
This test is intentionally truncating float to int, which MSVC
intentionally warns about, so push-disable-pop is necessary.
[libcxx] [test] Avoid truncation warnings in erase_if tests (NFC).
libcxx/test/std/containers/associative/map/map.erasure/erase_if.pass.cpp
libcxx/test/std/containers/associative/multimap/multimap.erasure/erase_if.pass.cpp
libcxx/test/std/containers/unord/unord.map/erase_if.pass.cpp
libcxx/test/std/containers/unord/unord.multimap/erase_if.pass.cpp
These tests use maps with `short` keys and values, emitting MSVC
truncation warnings from `int`. Adding `static_cast` to `key_type`
and `mapped_type` avoids these warnings.
As these tests require C++20 mode (or newer), for brevity I've changed
the multimap tests to use emplace to initialize the test data.
This has no effect on the erase_if testing.
* Silence unused-local-typedef warnings: `map.cons/assign_initializer_list.pass.cpp` (and the `set.cons` variant) uses a local typedef only within `LIBCPP_ASSERT`s, so clang diagnoses it as unused when testing non-libc++.
* Add missing include: `c.math/abs.pass.cpp` uses `std::numeric_limits` but failed to `#include <limits>`.
* Don't test non-type: A "recent" change to `meta.trans.other/underlying_type.pass.cpp` unconditionally tests the type `F` which is conditionally defined.
* Use `hash<long long>` instead of `hash<short>` with `int` in `unordered_meow` deduction guide tests to avoid truncation warnings.
* Convert `3.14` explicitly in `midpoint.float.pass` since MSVC incorrectly diagnoses `float meow = 3.14;` as truncating.
Differential Revision: https://reviews.llvm.org/D68681
llvm-svn: 374248
exceptions are disabled.
The patch was reverted due to some confusion about non-movable types. ie
types
that explicitly delete their move constructors. However, such types do
not meet
the requirement for `MoveConstructible`, which is required by
`std::vector`:
Summary:
`std::vector<T>` is free choose between using copy or move operations
when it
needs to resize. The standard only candidates that the correct exception
safety
guarantees are provided. When exceptions are disabled these guarantees
are
trivially satisfied. Meaning vector is free to optimize it's
implementation by
moving instead of copying.
This patch makes `std::vector` unconditionally move elements when
exceptions are
disabled. This optimization is conforming according to the current
standard wording.
There are concerns that moving in `-fno-noexceptions`mode will be a
surprise to
users. For example, a user may be surprised to find their code is slower
with
exceptions enabled than it is disabled. I'm sympathetic to this
surprised, but
I don't think it should block this optimization.
Reviewers: mclow.lists, ldionne, rsmith
Reviewed By: ldionne
Subscribers: zoecarver, christof, dexonsmith, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D62228
llvm-svn: 371867
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
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
This is a re-application of r362986 (which was reverted in r363688) with fixes
for the issue that caused it to be reverted.
Thanks to Arthur O'Dwyer for the patch.
Differential Revision: https://reviews.llvm.org/D58587
llvm-svn: 363968
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
Some tests assume that iteration through an unordered multiset elements
will return them in the same order as at the container creation. This
assumption is not true since the container is unordered, so that no
specific order of elements is ever guaranteed for such container. This
patch introduces checks verifying that any iteration will return
elements exactly from a set of valid values and without repetition,
but in no particular order.
Thanks to Andrey Maksimov for the patch.
Differential Revision: https://reviews.llvm.org/D56500
llvm-svn: 361494
Some tests assume that iteration through an unordered multimap elements
will return them in the same order as at the container creation. This
assumption is not true since the container is unordered, so that no
specific order of elements is ever guaranteed for such container. This
patch is a continuation of D54838 and introduces checks verifying that
any iteration will return elements exactly from a set of valid values
and without repetition, but in no particular order.
Thanks to Andrey Maksimov for the patch.
Differential Revision: https://reviews.llvm.org/D56498
llvm-svn: 361414
Some tests #include <iostream> but they don't use anything from the
header. Those are probably artifacts of when the tests were developped.
llvm-svn: 357181
Summary:
Freestanding is *weird*. The standard allows it to differ in a bunch of odd
manners from regular C++, and the committee would like to improve that
situation. I'd like to make libc++ behave better with what freestanding should
be, so that it can be a tool we use in improving the standard. To do that we
need to try stuff out, both with "freestanding the language mode" and
"freestanding the library subset".
Let's start with the super basic: run the libc++ tests in freestanding, using
clang as the compiler, and see what works. The easiest hack to do this:
In utils/libcxx/test/config.py add:
self.cxx.compile_flags += ['-ffreestanding']
Run the tests and they all fail.
Why? Because in freestanding `main` isn't special. This "not special" property
has two effects: main doesn't get mangled, and main isn't allowed to omit its
`return` statement. The first means main gets mangled and the linker can't
create a valid executable for us to test. The second means we spew out warnings
(ew) and the compiler doesn't insert the `return` we omitted, and main just
falls of the end and does whatever undefined behavior (if you're luck, ud2
leading to non-zero return code).
Let's start my work with the basics. This patch changes all libc++ tests to
declare `main` as `int main(int, char**` so it mangles consistently (enabling us
to declare another `extern "C"` main for freestanding which calls the mangled
one), and adds `return 0;` to all places where it was missing. This touches 6124
files, and I apologize.
The former was done with The Magic Of Sed.
The later was done with a (not quite correct but decent) clang tool:
https://gist.github.com/jfbastien/793819ff360baa845483dde81170feed
This works for most tests, though I did have to adjust a few places when e.g.
the test runs with `-x c`, macros are used for main (such as for the filesystem
tests), etc.
Once this is in we can create a freestanding bot which will prevent further
regressions. After that, we can start the real work of supporting C++
freestanding fairly well in libc++.
<rdar://problem/47754795>
Reviewers: ldionne, mclow.lists, EricWF
Subscribers: christof, jkorous, dexonsmith, arphaman, miyuki, libcxx-commits
Differential Revision: https://reviews.llvm.org/D57624
llvm-svn: 353086
The unordered_set and unordered_multiset iterators are specified in the standard as follows:
using iterator = implementation-defined; // see [container.requirements]
using const_iterator = implementation-defined; // see [container.requirements]
using local_iterator = implementation-defined; // see [container.requirements]
using const_local_iterator = implementation-defined; // see [container.requirements]
The pairs iterator/const_iterator and local_iterator/const_local_iterator
are not required to be the same. The reasonable requirement would be that
iterator can convert to const_iterator and local_iterator can convert to
const_local_iterator. This patch weakens the check and makes the test
more portable.
Reviewed as https://reviews.llvm.org/D56493.
Thanks to Andrey Maksimov for the patch.
llvm-svn: 352083
to reflect the new license. These used slightly different spellings that
defeated my regular expressions.
We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.
Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.
llvm-svn: 351648
Summary:
Starting in Clang 8.0 and GCC 8.0, `alignof` and `__alignof` return different values in same cases. Specifically `alignof` and `_Alignof` return the minimum alignment for a type, where as `__alignof` returns the preferred alignment. libc++ currently uses `__alignof` but means to use `alignof`. See llvm.org/PR39713
This patch introduces the macro `_LIBCPP_ALIGNOF` so we can control which spelling gets used.
This patch does not introduce any ABI guard to provide the old behavior with newer compilers. However, if we decide that is needed, this patch makes it trivial to implement.
I think we should commit this change immediately, and decide what we want to do about the ABI afterwards.
Reviewers: ldionne, EricWF
Reviewed By: ldionne, EricWF
Subscribers: jyknight, christof, libcxx-commits
Differential Revision: https://reviews.llvm.org/D54814
llvm-svn: 351289
There were 3 tests with 'int main(void)', and 6 with the return type on a different line. I'm about to send a patch for main in tests, and this NFC change is unrelated.
llvm-svn: 350770
We already have a specialization that will use memcpy for construction
of trivial types from an iterator range like
std::vector<int>(int *, int *);
But if we have const-ness mismatch like
std::vector<int>(const int *, const int *);
we would use a slow path that copies each element individually. This change
enables the optimal specialization for const-ness mismatch. Fixes PR37574.
Contributions to the patch are made by Arthur O'Dwyer, Louis Dionne.
rdar://problem/40485845
Reviewers: mclow.lists, EricWF, ldionne, scanon
Reviewed By: ldionne
Subscribers: christof, ldionne, howard.hinnant, cfe-commits
Differential Revision: https://reviews.llvm.org/D48342
llvm-svn: 350583
Some tests assume that iteration through an unordered multimap elements
will return them in the same order as at the container creation. This
assumption is not true since the container is unordered, so that no
specific order of elements is ever guaranteed for such container. This
patch introduces checks verifying that any iteration will return elements
exactly from a set of valid values and without repetition, but in no
particular order.
Reviewed as https://reviews.llvm.org/D54838.
Thanks to Andrey Maksimov for the patch.
llvm-svn: 349780
The standard section [array.zero] requires the return value of begin()
and end() methods of a zero-sized array to be unique. Eric Fiselier
clarifies: "That unique value cannot be null, and must be properly aligned".
This patch adds checks for the first part of this clarification: unique
value returned by these methods cannot be null.
Reviewed as https://reviews.llvm.org/D55366.
Thanks to Andrey Maksimov for the patch.
llvm-svn: 348509
The section array.zero says: "The return value of data() is unspecified".
This patch marks all checks of the array<T, 0>.data() return value as
libc++ specific.
Reviewed as https://reviews.llvm.org/D55364.
Thanks to Andrey Maksimov for the patch.
llvm-svn: 348485
This reverts commit 087f065cb0c7463f521a62599884493aaee2ea12.
The tests were failing on 32 bit builds, and I don't have time
to clean them up right now. I'll recommit tomorrow with fixed tests.
llvm-svn: 347816
Summary:
Starting in Clang 8.0 and GCC 8.0, `alignof` and `__alignof` return different values in same cases. Specifically `alignof` and `_Alignof` return the minimum alignment for a type, where as `__alignof` returns the preferred alignment. libc++ currently uses `__alignof` but means to use `alignof`. See llvm.org/PR39713
This patch introduces the macro `_LIBCPP_ALIGNOF` so we can control which spelling gets used.
This patch does not introduce any ABI guard to provide the old behavior with newer compilers. However, if we decide that is needed, this patch makes it trivial to implement.
I think we should commit this change immediately, and decide what we want to do about the ABI afterwards.
Reviewers: ldionne, EricWF
Reviewed By: EricWF
Subscribers: christof, libcxx-commits
Differential Revision: https://reviews.llvm.org/D54814
llvm-svn: 347787
The iterator types for different specializations of containers with the
same element type but different allocators are not required to be
convertible. This patch makes the test to take the iterator type from
the same container specialization as the created container.
Reviewed as https://reviews.llvm.org/D54806.
Thanks to Andrey Maksimov for the patch.
llvm-svn: 347423
Some tests use type std::max_align_t, but don't include <cstddef> header
directly. As a result, these tests won't compile against some conformant
libraries.
Reviewed as https://reviews.llvm.org/D54645.
Thanks to Andrey Maksimov for the patch.
llvm-svn: 347232
Louis Dionne