The aim is to define _LIBCPP_ELAST for AIX since strerror/strerror_r
can't handle out-of-range errno values.
Differential Revision: https://reviews.llvm.org/D100986
This fixes a long standing issue where the triple is not always set
consistently in all configurations. This change also moves the
back-deployment Lit features to using the proper target triple
instead of using something ad-hoc.
This will be necessary for using from scratch Lit configuration files
in both normal testing and back-deployment testing.
Differential Revision: https://reviews.llvm.org/D102012
This resolves issues when the CMake in use on the host is too old to
configure libc++ properly, but Xcode has a sufficiently recent version.
It is technically possible for the reverse issue to happen, where the
Xcode version would be too old and the user-installed version would be
better, however in the context of our build bots, we use AppleClang on
Apple platforms, and the CMake shipped with Xcode should work with the
AppleClang shipped alongside that Xcode.
Differential Revision: https://reviews.llvm.org/D102083
Jobs that test with a more recent standard version run more tests, so
they take longer. We'll decrease the average latency by running them
first instead of last.
And remove the dedicated debug-iterator tests; we want to test this in all modes.
We have a CI step for testing the whole test suite with `--debug_level=1` now.
Part of https://reviews.llvm.org/D102003
And remove the dedicated debug-iterator test; we want to test this in all modes.
We have a CI step for testing the whole test suite with `--debug_level=1` now.
Part of https://reviews.llvm.org/D102003
This is a rough reapplication of the change that fixed std::to_address
to avoid relying on element_type (da456167). It is somewhat different
because the fix to avoid breaking Clang (which caused it to be reverted
in 347f69c55) was a bit more involved.
Differential Revision: https://reviews.llvm.org/D101638
This simply applies Howard's commit 4c80bfbd53 consistently
across all the associative and unordered container tests.
"unord.set/insert_hint_const_lvalue.pass.cpp" failed with `-D_LIBCPP_DEBUG=1`
before this patch; it was the only one that incorrectly reused
invalid iterator `e`. The others already used valid iterators
(generally `c.end()`); I'm just making them all match the same pattern
of usage: "e, then r, then c.end() for the rest."
Differential Revision: https://reviews.llvm.org/D101679
`__debug_less` ends up running the comparator up-to-twice per comparison,
because whenever `(x < y)` it goes on to verify that `!(y < x)`.
This breaks the strict "Complexity" guarantees of algorithms like
`inplace_merge`, which we test in the test suite. So, just skip the
complexity assertions in debug mode.
Differential Revision: https://reviews.llvm.org/D101677
The range of char pointers [data, data+size] is a valid closed range,
but the range [begin, end) is valid only half-open.
Differential Revision: https://reviews.llvm.org/D101676
This appears to be a bug in our string::assign: when assigning into
a longer string, from a shorter snippet of itself, we invalidate
iterators before doing the copy. We should invalidate them afterward.
Also drive-by improve the formatting of a function header.
Differential Revision: https://reviews.llvm.org/D101675
This allocator is not intended for libc++'s users to use;
it's strictly an implementation detail of `src/locale.cpp`.
So, move it to the `src/include/` directory.
Drive-by const-qualify its comparison operators.
For consistency with `__hidden_allocator` (defined in `src/thread.cpp`),
do *not* remove it from "libcxx/lib/libc++unexp.exp",
"libcxx/utils/symcheck-blacklists/linux_blacklist.txt", etc.
Differential Revision: https://reviews.llvm.org/D101293
On Windows, static vs DLL linking affects details in quite a few
cases, so it's good to have coverage for both cases.
Testing with static linking also increases coverage for a number of
cases and individual checks that have had to be waived for the DLL
case, and allows testing libc++experimental, increasing the number
of test cases actually executed by 180 (176 new tests from
libc++experimental and 4 ones that are XFAIL windows-dll).
Also drop the "generic-" prefix from these configuration names, as
they're perhaps not what the "generic" prefix intended originally
in the other generic-posix configurations.
Differential Revision: https://reviews.llvm.org/D101565
This reverts commit da456167, which broke the Clang build. I'm able to
reproduce it but I want to give myself a bit more time to investigate.
Differential Revision: https://reviews.llvm.org/D101638
In std::tuple, we should try to avoid calling std::is_copy_constructible
whenever we can to avoid surprising interactions with (I believe) compiler
builtins. This bug was reported in https://reviews.llvm.org/D96523#2730953.
The issue was that when tuple<_Up...> was the same as tuple<_Tp...>, we
would short-circuit the _Or (because sizeof...(_Tp) != 1) and go evaluate
the following `is_constructible<_Tp, const _Up&>...`. That shouldn't
actually be a problem, but see the analysis in https://reviews.llvm.org/D101770#2736470
for why it is with Clang and GCC.
Instead, after this patch, we check whether the constructed-from tuple
is the same as the current tuple regardless of the number of elements,
since we should always prefer the normal copy constructor in that case
anyway.
Differential Revision: https://reviews.llvm.org/D101770
This makes the libc++ tests more portable -- almost all of them should
now work on Windows, except for some tests that assume a shell is
available on the target. We should probably provide a way to exclude
those anyway for the purpose of running tests on embedded targets.
Differential Revision: https://reviews.llvm.org/D89495
This fixes the issue by implementing _And using the short-circuiting
SFINAE trick that we previously used only in std::tuple. One thing we
could look into is use the naive recursive implementation for disjunctions
with a small number of arguments, and use that trick with larger numbers
of arguments. It might be the case that the constant overhead for setting
up the SFINAE trick makes it only worth doing for larger packs, but that's
left for further work.
This problem was raised in https://reviews.llvm.org/D96523.
Differential Revision: https://reviews.llvm.org/D101661
This patch gets rid of technical debt around std::pointer_safety which,
I claim, is entirely unnecessary. I don't think anybody has used
std::pointer_safety in actual code because we do not implement the
underlying garbage collection support. In fact, P2186 even proposes
removing these facilities entirely from a future C++ version. As such,
I think it's entirely fine to get rid of complex workarounds whose goals
were to avoid breaking the ABI back in 2017.
I'm putting this up both to get reviews and to discuss this proposal for
a breaking change. I think we should be comfortable with making these
tiny breaks if we are confident they won't hurt anyone, which I'm fairly
confident is the case here.
Differential Revision: https://reviews.llvm.org/D100410
`test/std/ranges/range.access/range.access.cbegin/incomplete.compile.verify.cpp`
was accidentally copied (and apparently the author either forgot to
delete it or forgot to commit the deletion).
TEST=`ninja cxx && ninja check-cxx` locally
C++20 revised the definition of what it means to be an iterator. While
all _Cpp17InputIterators_ satisfy `std::input_iterator`, the reverse
isn't true. D100271 introduces a new test adaptor to accommodate this
new definition (`cpp20_input_iterator`).
In order to help readers immediately distinguish which input iterator
adaptor is _Cpp17InputIterator_, the current `input_iterator` adaptor
has been prefixed with `cpp17_`.
Differential Revision: https://reviews.llvm.org/D101242
This reverts one of the macros just added in D101613, because it turns out
that the <utility> header actually uses the identifiers __x, __y, __z.
We probably *shouldn't* use __z if it's reserved on Windows; but since
it's not causing us any active problem even on Windows, I think this is
the safest way to unbreak the test.
This reverts a224bf8ec4 and fixes the
underlying issue.
The underlying issue is simply that MSVC headers contains a define
like "#define __in", where __in is one macro in the MSVC Source
Code Annotation Language, defined in sal.h
Just use a different variable name than "__in"
__indirectly_readable_impl, and add "__in" to nasty_macros.h just
like the existing __out. (Also adding a couple more potentially
conflicting ones.)
Differential Revision: https://reviews.llvm.org/D101613
If libc++ is built as a DLL, calls to operator new within the DLL aren't
overridden if a user provides their own operator in calling code.
Therefore, the alloc counter doesn't pick up on allocations done within
std::string, so skip that check if running on windows. (Technically,
we could keep the checks if running on windows when not built as a DLL,
but trying to keep the conditionals simple.)
Differential Revision: https://reviews.llvm.org/D100219
A span has no idea what container (if any) "owns" its iterators, nor
under what circumstances they might become invalidated.
However, continue to use `__wrap_iter<T*>` instead of raw `T*` outside
of debug mode, because we've been shipping `std::span` since Clang 7
and ldionne doesn't want to break ABI. (Namely, the mangling of functions
taking `span::iterator` as a parameter.) Permit using raw `T*` there,
but only under an ABI macro: `_LIBCPP_ABI_SPAN_POINTER_ITERATORS`.
Differential Revision: https://reviews.llvm.org/D101003
To run llvm-lit manually from the command line:
./bin/llvm-lit -sv --param std=c++2b --param cxx_under_test=`pwd`/bin/clang \
--param debug_level=1 ../libcxx/test/
Tests that currently fail with `debug_level=1` are marked `LIBCXX-DEBUG-FIXME`,
but my intent is to deal with all of them and leave no such annotations in
the codebase within the next couple weeks. (I have patches for all of them
in my local checkout.)
Differential Revision: https://reviews.llvm.org/D100866
This line was confusing some people: it's not supposed to indicate
any kind of problem with the script, and I can't see any way it could
even help with troubleshooting. So, just silence it.
* `std::ranges::range`
* `std::ranges::sentinel_t`
* `std::ranges::range_difference_t`
* `std::ranges::range_value_t`
* `std::ranges::range_reference_t`
* `std::ranges::range_rvalue_reference_t`
* `std::ranges::common_range`
`range_size_t` depends on `sized_range` and will be added alongside it.
Implements parts of:
* P0896R4 The One Ranges Proposal`
Depends on D100255.
Differential Revision: https://reviews.llvm.org/D100269
As these jobs only run in a couple seconds, and block starting of
other jobs, they can run on the "service" queue which doesn't get
blocked by other long-running jobs.
Differential Revision: https://reviews.llvm.org/D101437
While working on D70631, Microsoft's unit tests discovered an issue.
Our `std::to_chars` implementation for bases != 10 uses the range
`[first,last)` as temporary buffer. This violates the contract for
to_chars:
[charconv.to.chars]/1 http://eel.is/c++draft/charconv#to.chars-1
`to_chars_result to_chars(char* first, char* last, see below value, int base = 10);`
"If the member ec of the return value is such that the value is equal to
the value of a value-initialized errc, the conversion was successful and
the member ptr is the one-past-the-end pointer of the characters
written."
Our implementation modifies the range `[member ptr, last)`, which causes
Microsoft's test to fail. Their test verifies the buffer
`[member ptr, last)` is unchanged. (The test is only done when the
conversion is successful.)
While looking at the code I noticed the performance for bases != 10 also
is suboptimal. This is tracked in D97705.
This patch fixes the issue and adds a benchmark. This benchmark will be
used as baseline for D97705.
Reviewed By: #libc, Quuxplusone, zoecarver
Differential Revision: https://reviews.llvm.org/D100722
As the libcxx tests link with -nostdlib, libraries that normally
are added by default by the compiler driver has to be added
manually.
The "oldnames" library is automatically added when driving linking
with clang-cl. When linking with the plain clang driver, as the
libcxx tests do, the clang driver does the same but only since Clang
12.0). But when linking with -nostdlib, like the libcxx tests do,
the driver defaults aren't added at all, and we need to specify the
defaults manually.
This allows removing a TODO from the Windows CI setup; it turns out
that upgrading to Clang 12.0 didn't help here as expected, sorry about
that mixup.
Differential Revision: https://reviews.llvm.org/D101434
When using the per-target runtime build, it may be desirable to have
different __config_site headers for each target where all targets cannot
share a single configuration.
The layout used for libc++ headers after this change is:
```
include/
c++/
v1/
<libc++ headers except for __config_site>
<target1>/
c++/
v1/
__config_site
<target2>/
c++/
v1/
__config_site
<other targets>
```
This is the most optimal layout since it avoids duplication, the only
headers that's per-target is __config_site, all other headers are
shared across targets. This also means that we no need two
-isystem flags: one for the target-agnostic headers and one for
the target specific headers.
Differential Revision: https://reviews.llvm.org/D89013
In particular, `span<int>::iterator` may be a raw pointer type
and thus have no nested typedef `iterator::value_type`. However,
we already know that the value_type we expect for `span<int>` is just `int`.
Fix up all other iterator_concept_conformance tests in the same way.
Differential Revision: https://reviews.llvm.org/D101420
This is a partial revert of b4537c3f51
based on the discussion in https://reviews.llvm.org/D101194. Rather
than using the getMultiarchTriple, we use the getTripleString.
These are caused due to inconsistencies regarding always inline in
combination with dllimport. A bug report reference is added next to
each XFAIL line.
Differential Revision: https://reviews.llvm.org/D100789
This allows distinguishing failures in tests that only fail when libcxx
is linked as a DLL, allowing narrowing down XFAILs (avoiding XPASS errors
if not built as a DLL).
If both enable_shared and enable_static are set, the tests link and use
the shared version of the lib.
Differential Revision: https://reviews.llvm.org/D100221
Different platforms use different rules for multiarch triples so
it's difficult to provide a single method for all platforms. We
instead move the getMultiarchTriple to the ToolChain class and let
individual platforms override it and provide their custom logic.
Differential Revision: https://reviews.llvm.org/D101194
Support leak sanitizer in libcxx.
Simple addition for leak checking when running the libcxx testsuite.
Differential Revision: https://reviews.llvm.org/D100775
This reverts a large chunk of http://reviews.llvm.org/D15862 ,
and also fixes bugs in `insert`, `append`, and `assign`, which are now regression-tested.
(Thanks to Tim Song for pointing out the bug in `append`!)
Before this patch, we did a special dance in `append`, `assign`, and `insert`
(but not `replace`). All of these require the strong exception guarantee,
even when the user-provided InputIterator might have throwing operations.
The naive way to accomplish this is to construct a temporary string and
then append/assign/insert from the temporary; i.e., finish all the potentially
throwing and self-inspecting InputIterator operations *before* starting to
modify self. But this is slow, so we'd like to skip it when possible.
The old code (D15682) attempted to check that specific iterator operations
were nothrow: it assumed that if the iterator operations didn't throw, then
it was safe to iterate the input range multiple times and therefore it was
safe to use the fast-path non-naive version. This was wrong for two reasons:
(1) the old code checked the wrong operations (e.g. checked noexceptness of `==`,
but the code that ran used `!=`), and (2) the conversion of value_type to char
could still throw, or inspect the contents of self.
The new code is much simpler, although still much more complicated than it
really could be. We'll likely revisit this codepath at some point, but for now
this patch suffices to get it passing all the new regression tests.
The added tests all fail before this patch, and succeed afterward.
See https://quuxplusone.github.io/blog/2021/04/17/pathological-string-appends/
Differential Revision: https://reviews.llvm.org/D98573
This allows us to turn -Wdeprecated-copy back on. We turned it off
in 3b71de41cc because Clang's implementation became more stringent
and started diagnosing the old code here.
Differential Revision: https://reviews.llvm.org/D101183
During the review of D97115 it was mentioned adding the `<utility>`
header for `__to_underlying` was a bit unfortunate. Nowadays we tend to
implement smaller headers, so a good reason to move `std::to_underlying`
to its own header and adjust `<charconv>` to use the new header.
Differential Revision: https://reviews.llvm.org/D101233
A status page for libc++'s Format library. The page is inspired by
@zoecarver's Ranges status page.
Differential Revision: https://reviews.llvm.org/D101085
Implements parts of:
* P0896R4 The One Ranges Proposal`
Depends on D100073.
Reviewed By: ldionne, zoecarver, #libc
Differential Revision: https://reviews.llvm.org/D100080
This functionality is tested in std/containers/sequences/vector/iterators.pass.cpp
(and similarly for all containers, but vector is the only one to be tested that
uses debug iterators).
Differential Revision: https://reviews.llvm.org/D100881
This nasty patch rewrites the tuple constructors to match those defined
by the Standard. We were previously providing several extensions in those
constructors - those extensions are removed by this patch.
The issue with those extensions is that we've had numerous bugs filed
against us over the years for problems essentially caused by them. As a
result, people are unable to use tuple in ways that are blessed by the
Standard, all that for the perceived benefit of providing them extensions
that they never asked for.
Since this is an API break, I communicated it in the release notes.
I do not foresee major issues with this break because I don't think the
extensions are too widely relied upon, but we can ship it and see if we
get complaints before the next LLVM release - that will give us some
amount of information regarding how much use these extensions have.
Differential Revision: https://reviews.llvm.org/D96523
That was originally committed in 04733181b5 and then reverted in
a9f11cc0d9 because it broke several people.
The problem was a missing include of __iterator/concepts.h, which has now
been fixed.
Differential Revision: https://reviews.llvm.org/D100073
The straightforward `AddLinkFlag('-lc++experimental')` approach doesn't
work on e.g. MSVC. For linking to libc++ itself, a more convoluted logic
is used (see configure_link_flags_cxx_library).
Differential Revision: https://reviews.llvm.org/D99177
The new layout more closely matches the layout used by other compilers.
This is only used when LLVM_ENABLE_PER_TARGET_RUNTIME_DIR is enabled.
Differential Revision: https://reviews.llvm.org/D100869
Implements parts of:
* P0896R4 The One Ranges Proposal`
Depends on D99873.
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D100073
Simplify the test code, and drive-by also test that these algorithms
return the right iterator as their return value.
Differential Revision: https://reviews.llvm.org/D100876
Implements parts of:
* P0896R4 The One Ranges Proposal
Depends on D99855.
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D99863
The debug mode tests for map/set's iterators construct empty
containers, making the code after the first increment meaningless.
It's never executed since the tests exit earlier.
It doesn't seem to be intentional, so the patch makes the tests
to construct containers that include at least one element.
Reviewed By: curdeius, Quuxplusone
Differential Revision: https://reviews.llvm.org/D100029
Certain fields of shared ptr have virtual functions and therefore
have their debug info homed in libc++. But if libc++ wasn't built
with debug info, the pretty printer would fail.
This patch makes the pretty printer tolerate such conditions and
updates the test harness.
This patch significantly reworks a previous attempt.
This addresses https://bugs.llvm.org/show_bug.cgi?id=48937
Differential Revision: https://reviews.llvm.org/D100610
Based on D100682 and D99855.
(Note: I originally was going to just make this part of D99855, but I decided not to because this patch moves lots of unrelated code around, and I didn't want to make D99855 harder to review because of unrelated code-changes/moves.)
Differential Revision: https://reviews.llvm.org/D100686
* adds `iterator_traits` specialisation that supports all expected
member aliases except for `pointer`
* adds `iterator_traits` specialisations for iterators that meet the
legacy iterator requirements but might lack multiple member aliases
* makes pointer `iterator_traits` specialisation require objects
Depends on D99854.
Differential Revision: https://reviews.llvm.org/D99855
This continues the work started by @ldionne in 2908eb20ba.
The debug mode tests from
- libcxx/containers/sequences/vector/
- libcxx/strings/basic.string/string.access/
- libcxx/strings/basic.string/string.iterators/
similarly contain two tests in every file making the second test never
run. The patch splits the tests into separate files.
Reviewed By: Quuxplusone, ldionne
Differential Revision: https://reviews.llvm.org/D100592
On Windows, one can't use perms::none on a directory to trigger
failures to read the directory entries.
These remaining tests can't use GetWindowsInaccessibleDir() sensibly,
e.g. for tests that rely on toggling accessibility back and forth during
the test, or where the semantics of the dir provided by
GetWindowsInaccessibleDir() doesn't allow for running the ifdeffed tests
meaningfully.
Differential Revision: https://reviews.llvm.org/D97538
Previously the decision of which library to try to autolink was
based on _DLL, however the _DLL define (which is set by the compiler)
is tied to whether using a dynamically linked CRT or not, and the choice
of dynamic or static CRT is entirely orthogonal to whether libc++ is
linked dynamically or statically.
If _LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS isn't defined, then all
declarations are decorated with dllimport, and there's no doubt that
the DLL version of the library is what must be linked.
_LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS is defined if building with
LIBCXX_ENABLE_SHARED disabled, and thus the static library is what
should be linked.
If defining _LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS manually but wanting
to link against the DLL version of the library, that's not a canonical
configuration, and then it's probably reasonable to manually define
_LIBCPP_NO_AUTO_LINK too, and manually link against the desired
library.
This fixes, among other issues, running tests for the library if
built with LIBCXX_ENABLE_STATIC disabled.
Differential Revision: https://reviews.llvm.org/D100539
Since we have a tool to detect cycles now; and since we're entering
a phase where people can easily introduce cycles by accident (D100682)
or by request (D90999), I think it's increasingly important to shift
the burden of detecting these cycles onto the buildbot instead of
the poor human reviewer.
Also, grep for non-ASCII characters (such as U+200B and U+00AD)
and hard tabs; don't let those get checked in.
Differential Review: https://reviews.llvm.org/D100703
This is the initial patch to implement ranges in libc++.
Implements parts of:
- P0896R4 One Ranges Proposal
- P1870 forwarding-range is too subtle
- LWG3379 in several library names is misleading
Reviewed By: ldionne, #libc, cjdb, zoecarver, Quuxplusone
Differential Revision: https://reviews.llvm.org/D90999
This patch fixes LWG2874. It is based on the original patch by Zoe Carver
originally uploaded at D81417.
Differential Revision: https://reviews.llvm.org/D81417
This is a workaround for PR48937. GDB can sometimes print additional
warnings which currently fails the test. Use re.search instead of
re.match to ignore this additional output.
Differential Revision: https://reviews.llvm.org/D99532
The `iterator_traits` patch became too large for a concise review, so
the "bloat" —as it were— was moved into this patch. Also tests most
C++[98,17] iterator types to confirm backwards compatibility is
successful (regex iterators are intentionally not present, but directory
iterators are due to a peculiar error encountered while patching
`iterator_traits`).
Depends on D99461.
Differential Revision: https://reviews.llvm.org/D99854
Implements parts of:
* P0896R4 The One Ranges Proposal
* LWG3446 `indirectly_readable_traits` ambiguity for types with both `value_type` and `element_type`
Depends on D99141.
Differential Revision: https://reviews.llvm.org/D99461
In 5fd17ab, we worked around the Apple system headers not providing
const-correct overloads for some <string.h> functions. However, that
required an attribute that was only present in recent Clangs at the
time. We can now assume that all supported Clang versions on Apple
platforms do support that attribute.
Differential Revision: https://reviews.llvm.org/D100477
This makes it clear that headers like <memory> which include auto_ptr
only do that when compiling under an older Standard, or when the removed
feature is explicitly requested.
Some of Microsoft's unit tests in D70631 fail because libc++'s
implementation of std::chars_format isn't a proper bitmask type. Adding
the required functions to make std::chars_format a proper bitmask type.
Implements parts of P0067: Elementary string conversions
Differential Revision: https://reviews.llvm.org/D97115
The added documents have two tables: 1 containing links to issues and papers related to ranges. And the other contains most of the sections from the One Ranges Proposal, with their dependencies linked. This will allow us to assign work that can be done in parallel.
Differential Revision: https://reviews.llvm.org/D100393
Summary:
When building with gcc on AIX, it seems that gcc does not like the
`always_inline` without the `inline` keyword.
So adding the inline keywords in for __open in ifstream and ofstream.
That will also make it consistent with __open in basic_filebuf
(it seems we added `inline` there before for gcc build as well).
Differential Revision: https://reviews.llvm.org/D99422
The checks did not work in __config, since no header defining
`_NEWLIB_VERSION` was included before. This patch moves the two
checks for newlib to the headers that actually need it - and after
they already include relevant headers.
Differential Revision: https://reviews.llvm.org/D79888
These [[nodiscard]] annotations are added as a conforming extension;
it's unclear whether the paper will actually be adopted and make them
mandatory, but they do seem like good ideas regardless.
https://isocpp.org/files/papers/D2351R0.pdf
This patch implements the paper's effect on:
- std::to_integer, std::to_underlying
- std::forward, std::move, std::move_if_noexcept
- std::as_const
- std::identity
The paper also affects (but libc++ does not yet have an implementation of):
- std::bit_cast
Differential Revision: https://reviews.llvm.org/D99895
`__decay_copy` is used by `std::thread`'s constructor to copy its arguments
into the new thread. If `__decay_copy` claims to be noexcept, but then
copying the argument does actually throw, we'd call std::terminate instead
of passing this test. (And I've verified that adding an unconditional `noexcept`
to `__decay_copy` does indeed fail this test.)
Differential Revision: https://reviews.llvm.org/D100277
After this patch, we can use `--param std=c++20` even if the compiler only
supports -std=c++2a. The test suite will handle that for us. The only Lit
feature that isn't fully baked will always be the "in development" one,
since we don't know exactly what year the standard will be ratified in.
This is another take on https://reviews.llvm.org/D99789.
Differential Revision: https://reviews.llvm.org/D100210
This adds a CI job validating that the output of
utils/generate_feature_test_macro_components.py,
libcxx/utils/generate_header_inclusion_tests.py, and
utils/generate_header_tests.py are up to date.
The validation method has been copied from the Format job.
Differential Revision: https://reviews.llvm.org/D99862
Summary:
AIX system's stdlib.h provide different overload of abs and div
depending on compiler versions.
For example, std::div(long, long) and std::abs(long) are not available
from OS's stdlib.h when building with clang, but they are available
when building with xlclang compiler.
Therefore, we need to provide those extra overloads in libc++'s stdlib.h
when OS's stdlib.h does not.
Differential Revision: https://reviews.llvm.org/D99767
The document has the following updates:
- Rename 'feature test' to 'feature-test', the latter is the spelling
used in the Standard.
- Add information how an ABI list can be downloaded from Buildkite.
Differential Revision: https://reviews.llvm.org/D99290
* `std::predicate`
* `std::relation`
* `std::equivalence_relation`
* `std::strict_weak_order`
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/D96477
LWG3175 identifies that the `common_reference` requirement for
`swappable_with` is over-constraining and doesn't need to concern itself
with cv- or reference qualifiers.
Differential Revision: https://reviews.llvm.org/D99817
As mandated by the Standard's various synopses, e.g. [iterator.synopsis].
Searching the TeX source for '#include' is a good way to find all of these
mandates.
The new tests are all autogenerated by utils/generate_header_inclusion_tests.py.
I was SHOCKED by how many mandates there are, and how many of them
libc++ wasn't conforming with.
Differential Revision: https://reviews.llvm.org/D99309
The "user-defined conversion by implicit constructor" codepath is already
handled by `B(int)`; we don't need to test `A(const A&)` a second time
via `DA` (nor the isomorphic case with `DB`).
We don't need `&` anywhere in this test.
Generally, `operator()` should be const; this test needn't be special.
(No functional change in test coverage.)
If running in a Windows Container, there is no such directory at all.
If running from within bash on Windows Server, the directory seems to
be fully accessible. (The mechanics of this isn't fully understood, and
it doesn't seem to happen on desktop versions.)
If the directory isn't available with the expected behaviour, mark those
individual tests as unsupported. (The test as a whole is considered to
pass, but the unsupported test is mentioned in a test summary printed on
stdout.)
Differential Revision: https://reviews.llvm.org/D98960
Use `_LIBCPP_TEMPLATE_VIS` instead of `_LIBCPP_TYPE_VIS` for a template
class.
This fixes the nodiscard_extensions.pass.cpp and a couple
func.search.default test cases when built in MSVC/DLL configurations.
Differential Revision: https://reviews.llvm.org/D99932
This should be clearer, instead of relying on rules for implicit
conversions regarding built in float/integer types.
Differential Revision: https://reviews.llvm.org/D99928
* `std::predicate`
* `std::relation`
* `std::equivalence_relation`
* `std::strict_weak_order`
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/D96477
This patch fixes rc and errno within nanosleep(). It also updates __rem parameter as well it introduces cast to handle conversions from long into unsigned int to avoid warnings.
Reviewed By: Mordante
Differential Revision: https://reviews.llvm.org/D99373
Including `<concepts>` in other standard library headers (such as
`<iterator>`) creates circular dependencies due to `<functional>`.
Since `<concepts>` only needs `std::invoke` from `<functional>`, the
easiest, fastest, and cleanest way to eliminate the circular dep is to
move `std::invoke` into `__functional_base`.
This has the added advantage of `<concepts>` not transitively importing
`<functional>`.
Differential Revision: https://reviews.llvm.org/D99041
This improves the naming of the fields `depends`/`internal_depends`. It
also adds the documentation for this script. The changes are based on
D99290 and its review comments.
Differential Revision: https://reviews.llvm.org/D99615
This matches what we link the library itself against (set in
CMakeLists.txt). When testing a static library version of libc++,
this is needed for essentially every test due to libc++ object files
requiring it.
Also with libc++ built as a DLL, some tests directly call functions that
are provided by msvcprt (such as std::set_new_handler), thus this fixes
a number of tests in that configuration too.
Differential Revision: https://reviews.llvm.org/D99263
MSVC had a bug regarding preferring intergral conversions over
floating conversions. This is fixed in MSVC 19.28 and newer. Clang in
MSVC mode so far only mimics the old, buggy behaviour, but will
hopefully soon be fixed to comply with the new behaviour too
(see https://reviews.llvm.org/D99663).
Make the negative test to use a distinctly different type,
leaving checks for compiler specific bugs out of the libcxx test.
Differential Revision: https://reviews.llvm.org/D99641
This was requested in the review of D99175; rename the "runs"
variable to clarify what it means wrt the test, and move updating of
it to the main function to clarify its behaviour wrt the two runs
further.
Differential Revision: https://reviews.llvm.org/D99768
Implements parts of:
- P0898R3 Standard Library Concepts
- P1754 Rename concepts to standard_case for C++20, while we still can
Reviewed By: Mordante
Differential Revision: https://reviews.llvm.org/D98983
These seem to fail occasionally (they are marked as possibly requiring
a retry).
When doing a condvar wait_for(), it can wake up before the timeout
as a spurious wakeup. In these cases, the wait_for() method returns that
the timeout wasn't hit, and the test reruns another wait_for().
On Windows, it seems like the wait_for() operation often can end up
returning slightly before the intended deadline - when intending to
wait for 250 milliseconds, it can return after e.g. 235 milliseconds.
In these cases, the wait_for() doesn't indicate a timeout.
Previously, the test then reran a new wait_for() for a full 250
milliseconds each time. So for N consecutive wakeups slightly too early,
we'd wait for (N+1)*250 milliseconds. Now it only reruns wait_for() for
the remaining intended wait duration.
Differential Revision: https://reviews.llvm.org/D99175
This doesn't fail when _LIBCPP_HAS_NO_INT128 is defined consistently
in both CMAKE_CXX_FLAGS and LIBCXX_TEST_COMPILER_FLAGS; the XFAIL was
added based on early CI testruns where that flag was missing in
LIBCXX_TEST_COMPILER_FLAGS.
Differential Revision: https://reviews.llvm.org/D99705
Without this patch, we'd always try to codesign the first argument in
the command line, which in some cases is not something we can codesign
(e.g. `bash` for some .sh.cpp tests).
Note that this "hack" is the same thing we do in `ssh.py` - we might need
to admit that it's not a hack after all in the future, but I'm not ready
for that yet.
Differential Revision: https://reviews.llvm.org/D99726
These variables were introduced during early work on the runtimes build
but were obsoleted by {LIBCXX,LIBCXXABI,LIBUNWIND}_INSTALL_LIBRARY_DIR.
Differential Revision: https://reviews.llvm.org/D99697
This will avoid typos like `_LIBCPP_STD_VERS` (<future>) or using `#if TEST_STD_VER > 17` without including "test_macros.h".
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D99515
Because the constexpr-time codepath triggers a Clang bug. It seems
that Clang compiles it okay in release mode, but when Clang itself
is compiled in debug mode (with assertions turned on), this input
triggers an assertion failure in Clang itself. See comments on D96385
and Clang bug report https://bugs.llvm.org/show_bug.cgi?id=45879
This commit should get the debug-mode buildbots back to green.
The standard guarantees sleep durations of 2^63-1 nanoseconds to work.
Instead of depending on INT64_MAX or ULONGLONG_MAX to exist via the
header pollution, fold the constant directly. That has the additional
positive side effect that it avoids long double arithmetic bugs in GCC.
Differential Revision: https://reviews.llvm.org/D99516
Mark de Wever