Look for both kinds of slashes in include paths output from the
compiler.
Use "diff -w" to do a whitespace insensitive comparison, to ignore
differences in line endings (the python script writes to stdout
in text mode, with crlf newlines).
Differential Revision: https://reviews.llvm.org/D129428
It's unclear to me why this wasn't tagged this way already in
87fe0709d4 / D114612 where the
feature flag executor-has-no-bash was added, as this test did exist
in its current form already at that time.
Differential Revision: https://reviews.llvm.org/D131446
Increase the timeout tolerance if TEST_IS_EXECUTED_IN_A_SLOW_ENVIRONMENT
is set, similarly to how it's done in a couple other tests.
Use `std::this_thread::yield();` instead of busylooping. When multiple
threads are busylooping, it's plausible that not all threads even get
started running before the timeout runs out.
This makes the threading tests succeed if run in Windows runners on
Github Actions.
Differential Revision: https://reviews.llvm.org/D131483
This makes its role clearer. It's plausible that one may want to manually
define TEST_IS_EXECUTED_IN_A_SLOW_ENVIRONMENT when running the tests in
some environments - in particular, it seems to be necessary to use the
higher tolerance timeouts if running the tests on Windows runners
on Github Actions.
Also add the descriptive comment in one file where it was missing.
Differential Revision: https://reviews.llvm.org/D131484
The PATH is set in order to be able to find the tested DLL at runtime.
When linking statically, it's not necessary to set the PATH.
Setting PATH in the executor has the downside that it clears the
existing path (it's not prepended/appended to it), which means
that the executed tools can't find other tools - which sets the
executor-has-no-bash flag.
By removing the unnecessary setting of PATH, we have a properly
working bash even when wrapped by the executor, which gets rid
of the executor-has-no-bash flag in this test configuration, which
makes 9 more testcases be executed.
Differential Revision: https://reviews.llvm.org/D131481
When we ship LLVM 16, <ranges> won't be considered experimental anymore.
We might as well do this sooner rather than later.
Differential Revision: https://reviews.llvm.org/D132151
_HAS_EXCEPTIONS=0 allows disabling the exception parts of the MS STL
and vcruntime, and e.g. compiler-rt/lib/fuzzer sets this define (to
work around issues with MS STL). If using libc++ instead of MS STL,
this define previously broke the libc++ headers.
If _HAS_EXCEPTIONS is set to 0, the vcruntime_exception.h header
doesn't define the ABI base class std::exception. If no exceptions
are going to be thrown, this probably is fine (although it also
breaks using subclasses of it as regular objects that aren't thrown),
but it requires ifdeffing out all subclasses of all exception/error
derived objects (which are sprinkled throughout the headers).
Instead, libc++ will supply an ABI compatible definition when
_HAS_EXCEPTIONS is set to 0, which will make the class hierarchies
complete.
In this build configuration, one can still create instances of
exception subclasses, and those objects will be ABI incompatible
with the ones from when _HAS_EXCEPTIONS isn't defined to 0 - but
one may argue that's a pathological/self-imposed problem in that case.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D103947
Increasing the constexpr evaluation limit breaks this clang-tidy test
for GCC. As discussed in D131317 disable the test in GCC.
Reviewed By: philnik, #libc
Differential Revision: https://reviews.llvm.org/D131835
The new operator<=> is mapped onto the existing functions
__libcpp_thread_id_equal and __libcpp_thread_id_less. Introducing a
new __libcpp_thread_id_compare_three_way might lead to more efficient
code. Given that we can still introduce __libcpp_thread_id_compare_three_way
later, for this commit I opted to not break ABI. If requested, I will
add __libcpp_thread_id_compare_three_way in a follow-up commit.
Implements part of P1614R2 "The Mothership has Landed"
Differential Revision: https://reviews.llvm.org/D131362
I accidentally wrote `testComparisons(...)` instead of
`assert(testComparisons(...))`. This compiled without issues, but
did not provide the intended test coverage. By adding a `nodiscard`,
we can make sure that the compiler catches such mistakes for us.
Differential Revision: https://reviews.llvm.org/D131364
This patch fixes the max_size.pass.cpp test for PowerPC targets, depending on
endianness.
We will exhibit the full_size() behaviour for little endian
(where __endian_factor = 2 ), and the half_size() behaviour for
big endian (where __endian_factor = 1).
Differential Revision: https://reviews.llvm.org/D131682
Also, add missing tests for assertions in span constructors. Now I
believe that all of std::span's API should be hardened, and all the
assertions should have a corresponding test.
Differential Revision: https://reviews.llvm.org/D131681
Since bb939931a1, the c++experimental
library is always built, so these tested files should always be built
(even if they aren't used in tests).
Differential Revision: https://reviews.llvm.org/D129399
While implementing `operator<=>` for `string_view` (D130295) @philnik
pointed out `common_type` should be `type_identity`. Since it was an
existing issue that wasn't addressed.
This addresses the issue for both the new and existing equality and
comparison operators. The test is based on the example posted in
D130295.
Reviewed By: philnik, #libc, huixie90
Differential Revision: https://reviews.llvm.org/D131322
In D130295 @mumbleskates wondered why `std::strong_ordering::equal` had
special code since it's the same as `std::strong_ordering::equivalent`.
This is indeed the case so the special case can be removed.
Reviewed By: mumbleskates, #libc, avogelsgesang, ldionne
Differential Revision: https://reviews.llvm.org/D131419
D131234 marked the ranges papers as complete, but it didn't set the
feature-test macro.
Reviewed By: ldionne, var-const, #libc
Differential Revision: https://reviews.llvm.org/D131326
When back-deploying to older platforms, we can still provide assertions,
but we might not be able to provide a great implementation for the verbose
handler. Instead, we can just call ::abort().
Differential Revision: https://reviews.llvm.org/D131199
Evaluating `contiguous_iterator` on an iterator that satisfies all the
constraints except the `to_address` constraint and doesn't have
`operator->` defined results in a hard error. This is because
instantiating `to_address` ends up instantiating templates
dependent on the given type which might lead to a hard error even
in a SFINAE context.
Differential Revision: https://reviews.llvm.org/D130835
Also fix `ranges::stable_sort` and `ranges::inplace_merge` to support
proxy iterators now that their internal implementations can correctly
dispatch `rotate`.
Differential Revision: https://reviews.llvm.org/D130758
The return value for both of these algorithms is specified as
```
`{last, result - N}` for the overloads in namespace `ranges`.
```
But the current implementation instead returns `{first, result - N}`.
Also add both algorithms to the relevant "robust" tests.
Differential Revision: https://reviews.llvm.org/D130968
Propagate the complete host environment to the tests run via the new
testconfig. This ensures that all envvars needed e.g. for the compiler
to work correctly are present. This mimics the behavior explicitly
implemented in the legacy config.
https://github.com/llvm/llvm-project/issues/56816
Differential Revision: https://reviews.llvm.org/D130843
frederick-vs-ja noticed that https://github.com/microsoft/STL/pull/2976#issuecomment-1201926893
while we are working on updating LLVM submodule for MS STL:
[...]\std\numerics\rand\rand.dist\rand.dist.samp\rand.dist.samp.discrete\eval.pass.cpp(33): error C2220: the following warning is treated as an error
[...]\std\numerics\rand\rand.dist\rand.dist.samp\rand.dist.samp.discrete\eval.pass.cpp(287): note: see reference to function template instantiation 'void tests<__int64>(void)' being compiled
[...]\std\numerics\rand\rand.dist\rand.dist.samp\rand.dist.samp.discrete\eval.pass.cpp(33): warning C4244: 'argument': conversion from '__int64' to 'const unsigned int', possible loss of data
Differential Revision: https://reviews.llvm.org/D130963
This paper was accepted during the last plenary and is intended to be
backported to LLVM 15. When backporting the release notes in the branch
should be updated too.
Note the feature-test macro isn't updated since this will change; three
papers have updated the same macro in the same plenary.
Implements:
- P2508R1 Exposing std::basic-format-string
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D130643
This improves the formatting of the generated files. That allows it to
remove the clang-format step in D129668.
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D130911
The macro is only enabled when the Clang is used with
-fexperimental-library.
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D130792
I went over the output of the following mess of a command:
`(ulimit -m 2000000; ulimit -v 2000000; git ls-files -z | parallel --xargs -0 cat | aspell list --mode=none --ignore-case | grep -E '^[A-Za-z][a-z]*$' | sort | uniq -c | sort -n | grep -vE '.{25}' | aspell pipe -W3 | grep : | cut -d' ' -f2 | less)`
and proceeded to spend a few days looking at it to find probable typos
and fixed a few hundred of them in all of the llvm project (note, the
ones I found are not anywhere near all of them, but it seems like a
good start).
Reviewed By: #libc, philnik
Spies: philnik, libcxx-commits, mgorny, arichardson
Differential Revision: https://reviews.llvm.org/D130905
With the goal of reusing that handler to do other things besides
handling assertions (such as terminating when an exception is thrown
under -fno-exceptions), the name `__libcpp_assertion_handler` doesn't
really make sense anymore.
Furthermore, I didn't want to use the name `__libcpp_abort_handler`,
since that would give the impression that the handler is called
whenever `std::abort()` is called, which is not the case at all.
Differential Revision: https://reviews.llvm.org/D130562
Avoid relying on `iterator_traits` and instead deduce the return type of
dereferencing the iterator. Additionally, add a static check to reject
iterators with incorrect `iterator_traits` at compile time.
Differential Revision: https://reviews.llvm.org/D130538
Since the calendar is added in C++20 the existing operators are removed.
Implements part of:
- P1614R2 The Mothership has Landed
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D129887
- for all algorithms taking more than one range, add a `robust` test to
check the case where the ranges have different value types and the
given projections are different, with each projection applying to
a different value type;
- fix `ranges::include` to apply the correct projection to each range.
Differential Revision: https://reviews.llvm.org/D130515
Instead of taking a fixed set of arguments, use variadics so that
we can pass arbitrary arguments to the handler. This is the first
step towards using the handler to handle other non-assertion-related
failures, like std::unreachable and an exception being thrown in
-fno-exceptions mode, which would improve user experience by including
additional information in crashes (right now, we call abort() without
additional information).
Differential Revision: https://reviews.llvm.org/D130507
This adds a C++20-version of `reverse_iterator` which doesn't SFINAE away the operators for use inside the classic STL algorithms. Pre-C++20 `_AlgRevIter` is just an alias for `reverse_iterator`.
Reviewed By: var-const, #libc
Spies: huixie90, libcxx-commits
Differential Revision: https://reviews.llvm.org/D128864
This patch rewords the static assert diagnostic output. Failing a
_Static_assert in C should not report that static_assert failed. This
changes the wording to be more like GCC and uses "static assertion"
when possible instead of hard coding the name. This also changes some
instances of 'static_assert' to instead be based on the token in the
source code.
Differential Revision: https://reviews.llvm.org/D129048
mkstemp is guaranteed to make at least TMP_MAX attempts to create the
random file, and if it can't, it fails with EEXIST. get_temp_file_name
shouldn't call mkstemp again if it fails with anything other than
EEXIST. A single mkstemp call seems sufficient.
On Android, I've seen mkstemp fail with:
- EROFS (because cwd wasn't set to a writable filesystem)
- EACCES (because cwd pointed to a dir owned by root, but the test
program was running as the shell user instead)
Previously, get_temp_file_name would run forever in these situations.
See D4962 and "llvm-svn: 229035"
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D130214
When -fexperimental-library is passed, libc++ will now pick up the
appropriate __has_feature flag defined by Clang to enable the
experimental library features.
As a fly-by, also update the documentation for the various TSes.
Differential Revision: https://reviews.llvm.org/D130176
In D125283, we ensured that integer distributions would not compile when
used with arbitrary unsupported types. This effectively enforced what
the Standard mentions here: http://eel.is/c++draft/rand#req.genl-1.5.
However, this also had the effect of breaking some users that were
using integer distributions with unsupported types like int8_t. Since we
already support using __int128_t in those distributions, it is reasonable
to also support smaller types like int8_t and its unsigned variant. This
commit implements that, adds tests and documents the extension. Note that
we voluntarily don't add support for instantiating these distributions
with bool and char, since those are not integer types. However, it is
trivial to replace uses of these random distributions on char using int8_t.
It is also interesting to note that in the process of adding tests
for smaller types, I discovered that our distributions sometimes don't
provide as faithful a distribution when instantiated with smaller types,
so I had to relax a couple of tests. In particular, we do a really bad
job at implementing the negative binomial, geometric and poisson distributions
for small types. I think this all boils down to the algorithm we use in
std::poisson_distribution, however I am running out of time to investigate
that and changing the algorithm would be an ABI break (which might be
reasonable).
As part of this patch, I also added a mitigation for a very likely
integer overflow bug we were hitting in our tests in negative_binomial_distribution.
I also filed http://llvm.org/PR56656 to track fixing the problematic
distributions with int8_t and uint8_t.
Supersedes D125283.
Differential Revision: https://reviews.llvm.org/D126823
Looks like we again are going to have problems with libcxx tests that
are overly specific in their dependency on clang's diagnostics.
This reverts commit 6542cb55a3.
This patch is basically the rewording of the static assert statement's
output(error) on screen after failing. Failing a _Static_assert in C
should not report that static_assert failed. It’d probably be better to
reword the diagnostic to be more like GCC and say “static assertion”
failed in both C and C++.
consider a c file having code
_Static_assert(0, "oh no!");
In clang the output is like:
<source>:1:1: error: static_assert failed: oh no!
_Static_assert(0, "oh no!");
^ ~
1 error generated.
Compiler returned: 1
Thus here the "static_assert" is not much good, it will be better to
reword it to the "static assertion failed" to more generic. as the gcc
prints as:
<source>:1:1: error: static assertion failed: "oh no!"
1 | _Static_assert(0, "oh no!");
| ^~~~~~~~~~~~~~
Compiler returned: 1
The above can also be seen here. This patch is about rewording
the static_assert to static assertion.
Differential Revision: https://reviews.llvm.org/D129048
The return type was specified incorrectly for proxy iterators that
define `reference` to be a class that implicitly converts to
`value_type`. `__iter_move` would end up returning an object of type
`reference` which would then implicitly convert to `value_type`; thus,
the function will return a `value_type&&` rvalue reference to the local
temporary.
Differential Revision: https://reviews.llvm.org/D130197
This implements the Grapheme clustering as required by
P1868R2 width: clarifying units of width and precision in std::format
This was omitted in the initial patch, but the paper was marked as completed. This really completes the paper.
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D126971
The `ostream` `nullptr` inserter implemented in 3c125fe is missing a C++ version
guard. Normally, `libc++` takes the stance of backporting LWG issues to older
standards modes as was done in 3c125fe. However, backporting to older standards
modes breaks existing code in popular libraries such as `Boost.Test` and
`Google Test` who define their own overload for `nullptr_t`.
Instead, only apply this `operator<<` overload in C++17 or later.
Fixes https://github.com/llvm/llvm-project/issues/55861.
Differential Revision: https://reviews.llvm.org/D127033
In particular remove the ability to expel incomplete features from the
library at configure-time, since this can now be done through the
_LIBCPP_ENABLE_EXPERIMENTAL macro.
Also, never provide symbols related to incomplete features inside the
dylib, instead provide them in c++experimental.a (this changes the
symbols list, but not for any configuration that should have shipped).
Differential Revision: https://reviews.llvm.org/D128928
This caused build failures when building Clang and libc++ together on Mac:
fatal error: 'experimental/memory_resource' file not found
See the code review for details. Reverting until the problem and how to
solve it is better understood.
(Updates to some test files were not reverted, since they seemed
unrelated and were later updated by 340b48b267b96.)
> This is the first part of a plan to ship experimental features
> by default while guarding them behind a compiler flag to avoid
> users accidentally depending on them. Subsequent patches will
> also encompass incomplete features (such as <format> and <ranges>)
> in that categorization. Basically, the idea is that we always
> build and ship the c++experimental library, however users can't
> use what's in it unless they pass the `-funstable` flag to Clang.
>
> Note that this patch intentionally does not start guarding
> existing <experimental/FOO> content behind the flag, because
> that would merely break users that might be relying on such
> content being in the headers unconditionally. Instead, we
> should start guarding new TSes behind the flag, and get rid
> of the existing TSes we have by shipping their Standard
> counterpart.
>
> Also, this patch must jump through a few hoops like defining
> _LIBCPP_ENABLE_EXPERIMENTAL because we still support compilers
> that do not implement -funstable yet.
>
> Differential Revision: https://reviews.llvm.org/D128927
This reverts commit bb939931a1.
llvm-project\libcxx\test\std\time\time.hms\time.hms.members\seconds.pass.cpp(38): note: see reference to function template instantiation 'long check_seconds<std::chrono::seconds>(Duration)' being compiled
with
[
Duration=std::chrono::seconds
]
llvm-project\libcxx\test\std\time\time.hms\time.hms.members\seconds.pass.cpp(31): warning C4244: 'return': conversion from '_Rep' to 'long', possible loss of data
with
[
_Rep=__int64
]
Reviewed By: #libc, Mordante
Differential Revision: https://reviews.llvm.org/D129928
Summary:
The patch changes the definition of __regex_word to 0x8000 for AIX because the current definition 0x80 clashes with ctype_base::print (_ISPRINT is defined as 0x80 in AIX ctype.h).
Reviewed by: Mordante, hubert.reinterpretcast, libc++
Differential Revision: https://reviews.llvm.org/D129862
Since the calendar classes were introduced in C++20 there's no need to
keep the old comparison operators.
This commit does the day calender class, the other calendar classes will
be in a followup commit.
Implements parts of:
- P1614R2 The mothership has landed
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D128603
- create the headers (but not include them from `<algorithm>`);
- define the niebloid and its member functions with the right signatures
(as no-ops);
- make sure all the right headers are included that are required by each
algorithm's signature;
- update `CMakeLists.txt` and the module map;
- create the test files with the appropriate synopses.
The synopsis in `<algorithm>` is deliberately not updated because that
could be taken as a readiness signal. The new headers aren't included
from `<algorithm>` for the same reason.
Differential Revision: https://reviews.llvm.org/D129549
- checking that the algorithm supports predicates returning
a non-boolean type that's implicitly convertible to `bool`;
- checking that predicates and/or projections are invoked using
`std::invoke`.
Differential Revision: https://reviews.llvm.org/D129414
According to @aaron.ballman this was marked Tentatively Ready as of 2022-07-07.
D129362 implemented the C counterpart.
Reviewed By: ldionne, #libc, Mordante
Differential Revision: https://reviews.llvm.org/D129380
implement `std::ranges::set_intersection` by reusing the classic `std::set_intersenction`
added unit tests
Differential Revision: https://reviews.llvm.org/D129233
This implements a not accepted LWG issue. Not doing so would require
integral types to use the handle class instead of being directly stored
in the basic_format_arg.
The previous code used `std::forward` in places where it wasn't required
by the Standard. These are now removed.
Implements:
- P2418R2 Add support for std::generator-like types to std::format
- LWG 3631 basic_format_arg(T&&) should use remove_cvref_t<T> throughout
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D127570
This is the first part of a plan to ship experimental features
by default while guarding them behind a compiler flag to avoid
users accidentally depending on them. Subsequent patches will
also encompass incomplete features (such as <format> and <ranges>)
in that categorization. Basically, the idea is that we always
build and ship the c++experimental library, however users can't
use what's in it unless they pass the `-funstable` flag to Clang.
Note that this patch intentionally does not start guarding
existing <experimental/FOO> content behind the flag, because
that would merely break users that might be relying on such
content being in the headers unconditionally. Instead, we
should start guarding new TSes behind the flag, and get rid
of the existing TSes we have by shipping their Standard
counterpart.
Also, this patch must jump through a few hoops like defining
_LIBCPP_ENABLE_EXPERIMENTAL because we still support compilers
that do not implement -funstable yet.
Differential Revision: https://reviews.llvm.org/D128927
This commit re-applies 9ee97ce3b8, which was reverted by 61d417ce
because it broke the LLDB data formatter tests. It also re-applies
6148c79a (the manual GN change associated to it).
Differential Revision: https://reviews.llvm.org/D127444
It is meant to be used in ranges algorithm tests.
It is much simplified version of C++23's tuple + zip_view.
Using std::swap would cause compilation failure and using `std::move` would not create the correct rvalue proxy which would result in copies.
Differential Revision: https://reviews.llvm.org/D129099
With to_chars supporting 128-bit it's possible to support the full
128-bit range in format. This only removes the previous restrictions
and updates the tests to validate proper support.
Depends on D128929.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D129007
This is required by the Standard and makes it possible to add full
128-bit support to format.
The patch also fixes 128-bit from_chars "support". One unit test
required a too large value, this failed on 128-bit; the fix was to add
more characters to the input.
Note only base 10 has been optimized. Other bases can be optimized.
Note the 128-bit lookup table could be made smaller. This will be done later. I
really want to get 128-bit working in to_chars and format in the upcomming
LLVM 15 release, these optimizations aren't critical.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D128929
This changes the implementation of the formatter. Instead of inheriting
from a specialized parser all formatters will use the same generic
parser. This reduces the binary size.
The new parser contains some additional fields only used in the chrono
formatting. Since this doesn't change the size of the parser the fields
are in the generic parser. The parser is designed to fit in 128-bit,
making it cheap to pass by value.
The new format function is a const member function. This isn't required
by the Standard yet, but it will be after LWG-3636 is accepted.
Additionally P2286 adds a formattable concept which requires the member
function to be const qualified in C++23. This paper is likely to be
accepted in the 2022 July plenary.
This is based on D125606. That commit did the groundwork and did similar
changes for the string formatters.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D128785
Louis Dionne