This patch simplifies the implementation of `deque` by removing the `__deque_base` class which results in a lot less indirections and removes the need for `__base::`.
Reviewed By: ldionne, #libc
Spies: AdvenamTacet, libcxx-commits
Differential Revision: https://reviews.llvm.org/D132081
Many tests in `libcxx/test/std/strings` use
`#if defined(__cpp_lib_char8_t) && __cpp_lib_char8_t >= 201811L`
which can be replaced with the more terse `#ifndef TEST_HAS_NO_CHAR8_T`.
Differential Revision: https://reviews.llvm.org/D132626
This patch adds support for passing basic Lit features to the
ADDITIONAL_COMPILE_FLAGS keyword by enclosing them in parentheses.
This is done to support https://llvm.org/D131836.
In the future, we should instead add proper support for conditional
keywords in Lit, so that we can evaluate arbitrary Lit boolean
expressions such as `ADDITIONAL_COMPILE_FLAGS(x && !y): -flag`.
Note that I can see this being exceptionally useful when combined
with RUN commands, which would allow using different commands on
different systems. For example:
RUN(!buildhost=windows): something
RUN(buildhost=windows): something-else
Differential Revision: https://reviews.llvm.org/D132575
We don't use `clang::warn_unused_result` anymore, so let's remove the mentions of it from the tests
Reviewed By: Mordante, #libc
Spies: libcxx-commits
Differential Revision: https://reviews.llvm.org/D132339
D132284 has an approach to reduce the number of transitive includes
based on the language version used. This requires to be able to validate
changes in transitive includes in all language versions.
Due to issues in the experimental library c++03 will be done separately.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D132534
Otherwise, we would end up passing `-lNOTFOUND` to the compiler, which
caused various compiler checks to fail and ended up breaking the build
in the most obscure ways. For example, checks for -faligned-allocation
would fail because the compiler would complain about an unknown library
called NOTFOUND, and we would end up not passing -faligned-allocation
anywhere in our build. This is madness.
An even better alternative would be to simply FATAL_ERROR if we don't
find the builtins library. However, it seems like our build has been
working fine without finding it for a while, so instead of making a
bunch of builds fail, we can figure out why linking against compiler-rt
doesn't actually seem to be required in a follow-up, and perhaps
relax that.
This commit reverts the following commits:
- 952f90b72b
- e6a0800532 (D132298)
- 176db3b3ab (D132324)
These commits caused CI instability and need to be reverted in order
to figure things out again. See the discussion in https://llvm.org/D132324
for more information.
libc++ prior to LLVM 15 has a bug in it due to it excluding
`remove_reference_t` when `__remove_reference` is available as a
compiler built-in. This went unnoticed until D116203 because it wasn't
available in any compiler.
To work around this, we're renaming `__remove_reference` to
`__remove_reference_t`.
TEST=Tested locally, tested using emscripten
This has been officially deprecated since D112724, meaning the
deprecation warning is present in released 14 and 15.
This makes me think that now, shortly after the 15 release is branched,
is a good time to pull the trigger.
Reviewed By: phosek
Differential Revision: https://reviews.llvm.org/D132324
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
This was discussed on Discord with the consensus that we should rename the macros.
Reviewed By: ldionne, Mordante, var-const, avogelsgesang, jloser, #libc
Spies: libcxx-commits
Differential Revision: https://reviews.llvm.org/D131498
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
We held off on this before as `LLVM_LIBDIR_SUFFIX` conflicted with it.
Now we return this.
`LLVM_LIBDIR_SUFFIX` is kept as a deprecated way to set
`CMAKE_INSTALL_LIBDIR`. The other `*_LIBDIR_SUFFIX` are just removed
entirely.
I imagine this is too potentially-breaking to make LLVM 15. That's fine.
I have a more minimal version of this in the disto (NixOS) patches for
LLVM 15 (like previous versions). This more expansive version I will
test harder after the release is cut.
Reviewed By: sebastian-ne, ldionne, #libc, #libc_abi
Differential Revision: https://reviews.llvm.org/D130586
_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
Previously the specification was in a table in paragraph 14 of [container.requirements.general] but it has since been given its own sub section header, 24.2.2.4 [container.opt.reqmts].
This happened in 93ff092d1c
This update also includes misc. other cleanups of the spaceship projects sheet.
Reviewed By: Mordante, avogelsgesang, #libc
Differential Revision: https://reviews.llvm.org/D131928
An issue I often see in codebases compiled for unusual platforms is
that header search paths are specified manually and are subtly wrong.
For example, people will manually add `-isystem <some-toolchain>/usr/include`,
which ends up messing up the layering of header search paths required by
libc++ (because the C Standard Library now appears *before* libc++ in
the search paths). Without this patch, this will end up causing
compilation errors that are pretty inscrutable. This patch aims to
improve the user experience by diagnosing this issue explicitly.
In all cases I can think of, I would expect that a compilation error
occur if these header search paths are not layered properly. This
should only provide an explicit diagnostic instead of failing due
to seemingly unrelated compilation errors.
Differential Revision: https://reviews.llvm.org/D131441
While working on D129964 I noticed some code hadn't been uglyfied, this
rectifies the issue.
Depends on D129964
Reviewed By: #libc, philnik
Differential Revision: https://reviews.llvm.org/D131834
Since we branched LLVM install Clang 16 and remove Clang 12.
Currently our Docker installs 4 versions of Clang so our CI can use the
same image for both the main and the release branch. This wasn't done for
the other Clang tools so they always use the same version for testing
the main and the release branch. Instead install 2 versions for the
tools.
However it seems the default for Clang and its tools were the latest
released version instead of the ToT. To lessen the risk of breaking the
release CI, version 14 is installed hard-coded as a temporary solution.
Updating the main branch to use the Clang 16 compiler will be done in a
separate patch.
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D131324
This changes makes it easier to update the Unicode data files used for
the Extended Graphme Clustering as added in D126971.
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D129668
Warns on potentially unintended use of C++17 Class Template Argument
Deduction. Use of this feature with types that aren't intended to
support it may may future refactorings of those types more difficult -
so this warning fires whenever the feature is used with a type that may
not have intended to be used with CTAD (the warning uses the existence
of at least one explicit deduction guide to indicate that a type
intentionally supports CTAD - absent that, it's assumed to not be
intended to support CTAD & produces a warning).
This is disabled in libcxx because lots of the standard library is
assumed to provide ctad-usable APIs and the false positive suppression
in the diagnostic is based on system header classification which doesn't
apply in the libcxx build itself.
Differential Revision: https://reviews.llvm.org/D131727
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
The newly-completed papers:
- P0896R4 ("The One Ranges Proposal");
- P1243R4 ("Rangify New Algorithms");
- P1252R2 ("Ranges Design Cleanup");
- P1716R3 ("Range Comparison Algorithms Are Over-Constrained");
- P1871R1 ("Concept traits should be named after concepts");
- P2106R0 ("Alternative wording for GB315 and GB316").
Differential Revision: https://reviews.llvm.org/D131234
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
This is required for using clang-query in the CI
Reviewed By: Mordante, #libc
Spies: libcxx-commits, arichardson
Differential Revision: https://reviews.llvm.org/D130845
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
Trying to be generic didn't work properly because we had to special-case
some interface libraries that we didn't want in the linker script. Instead,
only look at the ABI and the unwinding libraries explicitly.
This should solve the issue reported by @dim in [1].
[1]: https://discourse.llvm.org/t/15-0-0-rc1-has-been-tagged/64174/22
Differential Revision: https://reviews.llvm.org/D131037
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
* `operator<=>` for `iota_view::iterator` was enabled in 8320017b79
* Removed P2405R0 which was not accepted and seems inactive
(https://github.com/cplusplus/papers/issues/1075)
* Added the previously missing `operator==` for `filesystem::space_info`
to the tracking list.
* Updated the "Assignee" for `string_view`, `string` as Mark de Wever
mentioned he is working on them in Discord
* Updated the status of the items for which I sent review requests
yesterday.
Reviewed By: #libc, Mordante
Differential Revision: https://reviews.llvm.org/D130855
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
Summary:
The AIX linker does not merge typeinfos when shared libraries are involved, which causes address comparison to fail although the types are the same. This patch changes to use the non-unique implementation for typeinfo comparison for AIX.
Reviewed by: hubert.reinterpretcast, philnik, libc++
Differential Revision: https://reviews.llvm.org/D130715
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
After evaluating the new style I noticed inner namespaces are now
indented. I am not fond of that style and I've seen some other review
comment in this regard so I propose we remove this option and use the
LLVM default not to indent it.
Reviewed By: ldionne, philnik, var-const, #libc
Differential Revision: https://reviews.llvm.org/D129441
Adds the papers and LWG issues voted in during the July 2022 plenary.
Note the updating of the project based statuses is left to the active
contributors of these projects.
Reviewed By: #libc, huixie90, philnik
Differential Revision: https://reviews.llvm.org/D130595
- 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
Leave the escape hatch in place with a note, but don't include the
debug mode symbols by default since we don't support the debug mode
in the normal library anymore.
This is technically an ABI break for users who were depending on
those debug mode symbols in the dylib, however those users will
already be broken at compile-time because they must have been using
_LIBCPP_DEBUG=2, which is now an error.
Differential Revision: https://reviews.llvm.org/D127360
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
D127650 removed support for non-clang-based XL compilers, but left some
of the headers used only by this compiler and included under the
__IBMCPP__ macro. This change cleans this up by deleting these headers.
Reviewed By: hubert.reinterpretcast, fanbo-meng
Differential Revision: https://reviews.llvm.org/D129491
Nobody knows if there are users of libc++ with MSVC. Let's try to find that out and encourage them to upstream their changes to make that configuration work.
Reviewed By: ldionne, #libc
Spies: libcxx-commits
Differential Revision: https://reviews.llvm.org/D129055
A format string like "{}" is quite common. In this case avoid parsing
the format-spec when it's not present. Before the parsing was always
called, therefore some refactoring is done to make sure the formatters
work properly when their parse member isn't called.
From the wording it's not entirely clear whether this optimization is
allowed
[tab:formatter]
```
and the range [pc.begin(), pc.end()) from the last call to f.parse(pc).
```
Implies there's always a call to `f.parse` even when the format-spec
isn't present. Therefore this optimization isn't done for handle
classes; it's unclear whether that would break user defined formatters.
The improvements give a small reduciton is code size:
719408 12472 488 732368 b2cd0 before
718824 12472 488 731784 b2a88 after
The performance benefits when not using a format-spec are:
```
Comparing ./formatter_int.libcxx.out-baseline to ./formatter_int.libcxx.out
Benchmark Time CPU Time Old Time New CPU Old CPU New
----------------------------------------------------------------------------------------------------------------------------------------------------
BM_Basic<uint32_t> -0.0688 -0.0687 67 62 67 62
BM_Basic<int32_t> -0.1105 -0.1107 73 65 73 65
BM_Basic<uint64_t> -0.1053 -0.1049 95 85 95 85
BM_Basic<int64_t> -0.0889 -0.0888 93 85 93 85
BM_BasicLow<__uint128_t> -0.0655 -0.0655 96 90 96 90
BM_BasicLow<__int128_t> -0.0693 -0.0694 97 90 97 90
BM_Basic<__uint128_t> -0.0359 -0.0359 256 247 256 247
BM_Basic<__int128_t> -0.0414 -0.0414 239 229 239 229
```
For the cases where a format-spec is used the results remain similar,
some are faster some are slower, differing per run.
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D129426
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
Change the mechanism in `iterator_operations.h` to pass around a generic
policy tag indicating whether an internal function is being invoked from
a "classic" STL algorithm or a ranges algorithm. `IterOps` is now
a template class specialized on the policy tag.
The advantage is that this mechanism is more generic and allows defining
arbitrary conditions in a clean manner.
Also add a few more iterator functions to `IterOps`.
Differential Revision: https://reviews.llvm.org/D129390
This header need not be included on non-z/OS IBM platforms (and indeed
will add nothing when it is), so add a guard. This let's us remove the
header without things breaking when shipping libc++ for AIX.
Reviewed By: hubert.reinterpretcast, fanbo-meng
Differential Revision: https://reviews.llvm.org/D129493
This is a preparation to look at possible performance improvements.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D129421
In our implementation the year is always less than or equal to the
class' `max()`. It's unlikely this ever changes since changing the
year's range will be an ABI break. A static_assert is added as a
guard.
This was reported by @philnik.
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D129442
- 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
As of now containers key_eq might get called when rehashing happens, which is redundant for unique keys containers.
Reviewed By: #libc, philnik, Mordante
Differential Revision: https://reviews.llvm.org/D128021
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
Since dfa88927ae, the static
libc++experimental should work in mingw dll builds. (It probably worked
all along in static mingw builds.)
Differential Revision: https://reviews.llvm.org/D129270
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 removes a part of the now obsolete formater code.
The removal also removes the _v2 suffix where it's no longer needed.
Depends on D128785
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D128846
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
Instead of marking private symbols with internal_linkage (which leads to
one copy per translation unit -- rather wasteful), use an ABI tag that
gets rev'd with each libc++ version. That way, we know that we can't have
name collisions between implementation-detail functions across libc++
versions, so we'll never violate the ODR. However, within a single program,
each symbol still has a proper name with external linkage, which means
that the linker is free to deduplicate symbols even across TUs.
This actually means that we can guarantee that versions of libc++ can
be mixed within the same program without ever having to take a code size
hit, and without having to manually opt-in -- it should just work out of
the box.
Differential Revision: https://reviews.llvm.org/D127444
After checking the libc++abi.dylib shipped in macOS 10.13, I can confirm
that it contains the align_val_t variants of operator new and operator
delete. However, the libc++abi.dylib shipped on macOS 10.12 does not.
Differential Revision: https://reviews.llvm.org/D129198
The number of spaces between `#` and `pragma` can differ due to
different indention levels in the preprocessor directives. Therefore
allow any number of spaces.
The test used to put an exclamation mark in its diagnostic. This adds
little benefit and only makes it harder to copy the offending filename.
As drive-by this exclamation mark has been removed.
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D129047
This way we ensure that we don't use-after-move the iterators.
Reviewed By: Mordante, #libc
Spies: libcxx-commits
Differential Revision: https://reviews.llvm.org/D129044
Both clang and GCC support using `__has_builtin` for detecting compiler-provided type_traits. Use it instead of `__has_keyword` or `__has_feature` to remove special-casing for GCC-provided builtins
Reviewed By: ldionne, #libc
Spies: libcxx-commits
Differential Revision: https://reviews.llvm.org/D129056
Display 'static_assert failed: message' instead of
'static_assert failed "message"' to be consistent
with other implementations and be slightly more
readable.
Reviewed By: #libc, aaron.ballman, philnik, Mordante
Differential Revision: https://reviews.llvm.org/D128844
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.
Depends on D128139.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D128671
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.
Depends on D125606
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D128139
Otherwise, this breaks freestanding builds, where `main()` isn't mangled
specially and we need to assume that we have a `int main(int, char**)`
entry point in each test for things to work.
- P1252 ("Ranges Design Cleanup") -- deprecate
`move_iterator::operator->` starting from C++20; add range comparisons
to the `<functional>` synopsis. This restores
`move_iterator::operator->` that was incorrectly deleted in D117656;
it's still defined in the latest draft, see
http://eel.is/c++draft/depr.move.iter.elem. Note that changes to
`*_result` types from 6.1 in the paper are no longer relevant now that
these types are aliases;
- P2106 ("Alternative wording for GB315 and GB316") -- add a few
`*_result` types to the synopsis in `<algorithm>` (some algorithms are
not implemented yet and thus some of the proposal still cannot be
marked as done);
Also mark already done issues as done (or as nothing to do):
- P2091 ("Fixing Issues With Range Access CPOs") was already implemented
(this patch adds tests for some ill-formed cases);
- LWG 3247 ("`ranges::iter_move` should perform ADL-only lookup of
`iter_move`") was already implemented;
- LWG 3300 ("Non-array ssize overload is underconstrained") doesn't
affect the implementation;
- LWG 3335 ("Resolve C++20 NB comments US 273 and GB 274") was already
implemented;
- LWG 3355 ("The memory algorithms should support move-only input
iterators introduced by P1207") was already implemented (except for
testing).
Differential Revision: https://reviews.llvm.org/D126053
This commit re-adds transitive includes that had been removed by
4cd04d1687, c36870c8e7, a83f4b9cda, 1458458b55, 2e2f3158c6,
and 489637e66d. This should cover almost all the includes that had
been removed since LLVM 14 and that would contribute to breaking user
code when releasing LLVM 15.
It is possible to disable the inclusion of these headers by defining
_LIBCPP_REMOVE_TRANSITIVE_INCLUDES. The intent is that vendors will
enable that macro and start fixing downstream issues immediately. We
can then remove the macro (and the transitive includes) by default in
a future release. That way, we will break users only once by removing
transitive includes in bulk instead of doing it bit by bit a every
release, which is more disruptive for users.
Note 1: The set of headers to re-add was found by re-generating the
transitive include test on a checkout of release/14.x, which
provided the list of all transitive includes we used to provide.
Note 2: Several includes of <vector>, <optional>, <array> and <unordered_map>
have been added in this commit. These transitive inclusions were
added when we implemented boyer_moore_searcher in <functional>.
Note 3: This is a best effort patch to try and resolve downstream breakage
caused since branching LLVM 14. I wasn't able to perfectly mirror
transitive includes in LLVM 14 for a few headers, so I added a
release note explaining it. To summarize, adding boyer_moore_searcher
created a bunch of circular dependencies, so we have to break
backwards compatibility in a few cases.
Differential Revision: https://reviews.llvm.org/D128661
Summary:
This patch ports libc++ LIT test cases for getting time in various locales to AIX.
Reviewed by: philnik, Mordante, libc++
Differential Revision: https://reviews.llvm.org/D128087
Summary:
This patch ports libc++ LIT test cases for money formats to AIX. On AIX, the money format of locale zh_CN.UTF-8 is the similar to that of en_US.UTF-8, i.e., sign, symbol, none, value.
Reviewed by: Mordante, DiggerLin, libc++
Differential Revision: https://reviews.llvm.org/D128220
Also, improve the test for nasty macros to define min and max, so this
will be caught in the future.
Differential Revision: https://reviews.llvm.org/D128655
It turns out that the Docker images on CI instances are not updated
based on what's in this file, but instead when a new image is pushed
to ldionne/libcxx-builder on DockerHub. So this is effectively useless.
Previously, we'd use raw pointers when the debug mode was enabled,
which means we wouldn't get out-of-range checking with std::span's
iterators.
This patch introduces a new class called __bounded_iter which can
be used to wrap iterators and make them carry around bounds-related
information. This allows iterators to assert when they are dereferenced
outside of their bounds.
As a fly-by change, this commit removes the _LIBCPP_ABI_SPAN_POINTER_ITERATORS
knob. Indeed, not using a raw pointer as the iterator type is useful to
avoid users depending on properties of raw pointers in their code.
This is an alternative to D127401.
Differential Revision: https://reviews.llvm.org/D127418
Summary:
Patch D123580 changed to use bit fields for strings in long and short mode. As a result, this changes the layout of these strings on AIX because bit fields on AIX are 4 bytes, which breaks the ABI compatibility with earlier strings before the change on AIX. This patch uses the attribute 'packed' and anonymous structure to make string layout compatible. This patch will also make test cases alignof.compile.pass.cpp and sizeof.compile.pass.cpp introduced in D127672 pass on AIX.
Reviewed by: philnik, Mordante, hubert.reinterpretcast, libc++
Differential Revision: https://reviews.llvm.org/D128285
1. for constructors that takes cvref variation of tuple<UTypes...>, there
used to be two SFINAE helper _EnableCopyFromOtherTuple,
_EnableMoveFromOtherTuple. And the implementations of these two helpers
seem to slightly differ from the spec. But now, we need 4 variations.
Instead of adding another two, this change refactored it to a single one
_EnableCtrFromUTypesTuple, which directly maps to the spec without
changing the C++11 behaviour. However, we need the helper __copy_cvref_t
to get the type of std::get<i>(cvref tuple<Utypes...>) for different
cvref, so I made __copy_cvref_t to be available in C++11.
2. for constructors that takes variations of std::pair, there used to be
four helpers _EnableExplicitCopyFromPair, _EnableImplicitCopyFromPair,
_EnableImplicitMoveFromPair, _EnableExplicitMoveFromPair. Instead of
adding another four, this change refactored into two helper
_EnableCtrFromPair and _BothImplicitlyConvertible. This also removes the
need to use _nat
3. for const member assignment operator, since the requirement is very
simple, I haven't refactored the old code but instead directly adding
the new c++23 code.
4. for const swap, I pretty much copy pasted the non-const version to make
these overloads look consistent
5. while doing these change, I found two of the old constructors wasn't
marked constexpr for C++20 but they should. fixed them and added unit
tests
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D116621
When merging the changes of <type_traits> header with the commits on
this header over the last month, several conflicts were mistaken
resolved and the wrong branch was picked while resolving conflicts,
which leads to CI failure. In order to resolve the conflicts properly
with qualification CI job, this change is reverted.
This reverts commit 95733a55b9.
1. for constructors that takes cvref variation of tuple<UTypes...>, there
used to be two SFINAE helper _EnableCopyFromOtherTuple,
_EnableMoveFromOtherTuple. And the implementations of these two helpers
seem to slightly differ from the spec. But now, we need 4 variations.
Instead of adding another two, this change refactored it to a single one
_EnableCtrFromUTypesTuple, which directly maps to the spec without
changing the C++11 behaviour. However, we need the helper __copy_cvref_t
to get the type of std::get<i>(cvref tuple<Utypes...>) for different
cvref, so I made __copy_cvref_t to be available in C++11.
2. for constructors that takes variations of std::pair, there used to be
four helpers _EnableExplicitCopyFromPair, _EnableImplicitCopyFromPair,
_EnableImplicitMoveFromPair, _EnableExplicitMoveFromPair. Instead of
adding another four, this change refactored into two helper
_EnableCtrFromPair and _BothImplicitlyConvertible. This also removes the
need to use _nat
3. for const member assignment operator, since the requirement is very
simple, I haven't refactored the old code but instead directly adding
the new c++23 code.
4. for const swap, I pretty much copy pasted the non-const version to make
these overloads look consistent
5. while doing these change, I found two of the old constructors wasn't
marked constexpr for C++20 but they should. fixed them and added unit
tests
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D116621
A situation that happens fairly often in libc++ is that we remove some
transitive includes in a header (either purposefully or not) and that
ends up breaking users. Of course, we want to be able to remove our
transitive includes, however it's also good to have a grip on that
to know which commit changed what and when. Furthermore, it's good
to accumulate include removals for a couple of releases to avoid
breaking users at every release for this reason.
This commit adds a test that should break whenever we remove an
include. Hence, it should allow us to track which headers include
which other headers transitively, giving us a traceable way to
remove headers.
Differential Revision: https://reviews.llvm.org/D128236
This is a helper patch to ease the reviewing of D128139.
The originals will be removed at a later time when all formatters are
converted to the new style. (Floating-point and pointer aren't up for
review yet.)
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D128367
This patch also adds a new optimization to `std::move`. It unwraps three `reverse_iterator`s if the wrapped iterator is a `contiguous_iterator` and the iterated type is trivially_movable. This allows us to simplify `ranges::move_backward` to a forward to `std::move` without any pessimization.
Reviewed By: var-const, #libc
Spies: libcxx-commits, mgorny
Differential Revision: https://reviews.llvm.org/D126616
`__GCC_CONSTRUCTIVE_SIZE` and `__GCC_DESTRUCTIVE_SIZE` are available since GCC 12. I'm assuming clang will also implement these for compatability with libstdc++.
Reviewed By: ldionne, #libc
Spies: h-vetinari, libcxx-commits, arichardson
Differential Revision: https://reviews.llvm.org/D122276
This is a follow up based on a request of @jloser in D127594.
As drive-by qualified the function calls in the <bit> header.
Reviewed By: #libc, EricWF
Differential Revision: https://reviews.llvm.org/D127760
Instead of instantiating all functions called by std::to_chars for the
integral types only instantiate them for 32 and 64 bit integral types.
This results in a smaller binary when using different types.
In an example using the types: signed char, short, int, long, long long,
unsigned char, unsigned short, unsigned int, unsigned long, and
unsigned long long this saved 2792 bytes of code size. For libc++.so.1
is saves 688 bytes of code size (64-bit Linux).
This was discovered while investigating a solution for #52709.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D128215
Nikolas Klauser