add_lit_testsuite() takes Lit parameters passed to it and adds them
to the parameters used globally when running all test suites. That
means that a target like `check-all`, which ends up calling Lit on
the whole monorepo, will see the test parameters for all the individual
project's test suites.
So, for example, it would see `--param std=c++03` (from libc++abi), and
`--param std=c++03` (from libc++), and `--param whatever` (from another
project being tested at the same time). While always unclean, that works
when the parameters all agree. However, if the parameters share the same
name but have different values, only one of those two values will be used
and it will be incredibly confusing to understand why one of the test
suites is being run with the incorrect parameter value.
For that reason, this commit moves away from using add_lit_testsuite()'s
PARAM functionality, and serializes the parameter values for the runtimes
in the generated config.py file instead, which is local to the specific
test suite.
Differential Revision: https://reviews.llvm.org/D105991
It turns out that D105040 broke `std::rel_ops`; we actually do need
both a one-template-parameter and a two-template-parameter version of
all the comparison operators, because if we have only the heterogeneous
two-parameter version, then `x > x` is ambiguous:
template<class T, class U> int f(S<T>, S<U>) { return 1; }
template<class T> int f(T, T) { return 2; } // rel_ops
S<int> s; f(s,s); // ambiguous between #1 and #2
Adding the one-template-parameter version fixes the ambiguity:
template<class T, class U> int f(S<T>, S<U>) { return 1; }
template<class T> int f(T, T) { return 2; } // rel_ops
template<class T> int f(S<T>, S<T>) { return 3; }
S<int> s; f(s,s); // #3 beats both #1 and #2
We have the same problem with `reverse_iterator` as with `__wrap_iter`.
But so do libstdc++ and Microsoft, so we're not going to worry about it.
Differential Revision: https://reviews.llvm.org/D105894
This commit reverts 5099e01568 and 77396bbc98, which broke the build
in various ways. I'm reverting until I can investigate, since that
change appears to be way more subtle than it seemed.
On Windows, structs with a destructor are always returned indirectly;
add this to the list of known exceptions in the test where the class
isn't returned in registers as expected.
Differential Revision: https://reviews.llvm.org/D105906
This is a second attempt at D101497, which landed as
9a9bc76c0e but had to be reverted in
8cf7ddbdd4.
This issue was that in the case that `COMPILER_RT_INSTALL_PATH` is
empty, expressions like "${COMPILER_RT_INSTALL_PATH}/bin" evaluated to
"/bin" not "bin" as intended and as was originally.
One solution is to make `COMPILER_RT_INSTALL_PATH` always non-empty,
defaulting it to `CMAKE_INSTALL_PREFIX`. D99636 adopted that approach.
But, I think it is more ergonomic to allow those project-specific paths
to be relative the global ones. Also, making install paths absolute by
default inhibits the proper behavior of functions like
`GNUInstallDirs_get_absolute_install_dir` which make relative install
paths absolute in a more complicated way.
Given all this, I will define a function like the one asked for in
https://gitlab.kitware.com/cmake/cmake/-/issues/19568 (and needed for a
similar use-case).
---
Original message:
Instead of using `COMPILER_RT_INSTALL_PATH` through the CMake for
complier-rt, just use it to define variables for the subdirs which
themselves are used.
This preserves compatibility, but later on we might consider getting rid
of `COMPILER_RT_INSTALL_PATH` and just changing the defaults for the
subdir variables directly.
---
There was a seaming bug where the (non-Apple) per-target libdir was
`${target}` not `lib/${target}`. I suspect that has to do with the docs
on `COMPILER_RT_INSTALL_PATH` saying was the library dir when that's no
longer true, so I just went ahead and fixed it, allowing me to define
fewer and more sensible variables.
That last part should be the only behavior changes; everything else
should be a pure refactoring.
---
I added some documentation of these variables too. In particular, I
wanted to highlight the gotcha where `-DSomeCachePath=...` without the
`:PATH` will lead CMake to make the path absolute. See [1] for
discussion of the problem, and [2] for the brief official documentation
they added as a result.
[1]: https://cmake.org/pipermail/cmake/2015-March/060204.html
[2]: https://cmake.org/cmake/help/latest/manual/cmake.1.html#options
In 38b2dec37e the problem was somewhat
misidentified and so `:STRING` was used, but `:PATH` is better as it
sets the correct type from the get-go.
---
D99484 is the main thrust of the `GnuInstallDirs` work. Once this lands,
it should be feasible to follow both of these up with a simple patch for
compiler-rt analogous to the one for libcxx.
Reviewed By: phosek, #libc_abi, #libunwind
Differential Revision: https://reviews.llvm.org/D105765
std::exchange is only constexpr in C++20 and later. We were using it
in a constructor marked unconditionally constexpr, which caused issues
when building with -std=c++17.
The weird part is that the issue only showed up when building on the
arm64 macs, but that must be caused by the specific version of Clang
used on those. Since the code is clearly wrong and the fix is obvious,
I'm not going to investigate this further.
Make sure that the detached thread has started up before exiting
the process.
This is exactly the same fix as D105592, with the same pattern
being present in a different test case.
Differential Revision: https://reviews.llvm.org/D105736
This is what ffccf96e90 should have enabled, however the symlink
in the Docker image was not pointing to the right compiler, so we were
testing with Clang 12 instead of ToT.
For reasons unknown, the build is now using compilers
from /usr/bin instead of /usr/local/bin which is where
we have our clang-12 aliases placed.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D105704
This will allow us to use variant in common_iterator. We do this by introducing a new `__light_array` type that variant uses instead of `std::array`.
Differential Revision: https://reviews.llvm.org/D105597
It makes the most sense to test with Clang ToT by default since that's
exactly what we're trying to QA: that libc++ works with whatever compiler
we're going to release next.
The compiler support policy mentions that we support Clang 11 and 12, so
we should test those. We already test on Clang 12, but I'll add testers
for Clang 11 once the new Docker image is in use on all the builders.
This is the first of a few commits that update the CI to match the
recently officialized compiler support policy. I'm staging those
changes to try and keep the CI green at all times, accounting how
builders refresh their Docker image.
The format library uses `std::monostate`, but not a `std::variant`.
Moving `std::monostate` to its own header allows the format library to
reduce the amount of included code.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D105582
The unit tests test some implementation details. As @Quuxplusone pointed
out in D96664 this should only be tested when the tests use libc++. This
addresses the issue for code already in main.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D105568
Make sure that the detached thread has started up before exiting
the process.
If the detached thread hasn't started up at all, and the main thread
exits, global data structures in the process are torn down, which
then can cause crashes when the thread starts up late after required
mutexes have been destroyed. (In particular, the mutex used internally
in _Init_thread_header, which is used in the initialization of
__thread_local_data()::__p, can cause crashes if the main thread already
has finished and progressed far with destruction.)
Differential Revision: https://reviews.llvm.org/D105592
I'm not sure what that gains us, and it creates a problem when
trying to run the tests against libc++ with a custom install name
dir (e.g. /usr/lib), since the library that we link against (in
the build tree) will advertise itself as /usr/lib/libc++.dylib,
so we end up linking against the system dylib at runtime.
Differential Revision: https://reviews.llvm.org/D105499
This patch overhauls the documentation around building libc++
for vendors, and using libc++ for end-users. It also:
- Removes mention of the standalone build, which we've been trying to
get rid of for a long time.
- Removes mention of using a local ABI installation, which we don't do
and is documented as "not recommended".
- Removes mention of the separate libc++filesystem.a library, which isn't
relevant anymore since filesystem support is in the main library.
- Adds mention of the GDB pretty printers and how to use them.
This is necessary for from-scratch configurations to support the 32-bit
mode of the test suite.
Differential Revision: https://reviews.llvm.org/D105435
Now that Lit supports regular expressions inside XFAIL & friends, it is
much easier to write Lit annotations based on the triple.
Differential Revision: https://reviews.llvm.org/D104747
Summary:
If we are on c++03 mode for some reason, and __builtin_va_copy is
available, then use it instead of error out on not having va_copy
in 03 mode.
Reviewed by: ldionne
Differential Revision: https://reviews.llvm.org/D100336
This is required to run the tests under any configuration that uses
additional_features using a from-scratch config. That is the case of
e.g. the Debug mode (which uses LIBCXX-DEBUG-FIXME) and the tests on
Windows.
The various design docs have been moved to RST, and the linked blog post
does not apply anymore since libc++ is the default library used by Clang
on Apple platforms.
While we can debate on the value of passing by const value, there is no
arguing that it's confusing to do so in some circumstances, such as when
marking a pointer parameter as being const (did you mean a pointer-to-const?).
This commit fixes a few issues along those lines.
The __search helper function was once split into __functional for circular
dependency reasons, however this is not an issue anymore now that we have
finer grained headers.
Before this patch, Lit parameters that were set as a result of CMake
options were not made available to from-scratch configs. This patch
serializes those parameters into the generated lit config file so that
they are available to all configs.
Differential Revision: https://reviews.llvm.org/D105047
This patch is to fix 2 libcxx test cases, test cases assumed 'a' > 'A' which is not case in z/OS platform on ebcdic mode, modified test cases to compare between upper letters or lower letters, or digits so ordering will be true for all platform.
Differential Revision: https://reviews.llvm.org/D104748
With the STL containers, I didn't enable move operations in C++03 mode
because that would change the overload resolution for things that today
are copy operations. With iostreams, though, the copy operations aren't
present at all, and so I see no problem with enabling move operations
even in (Clang's greatly extended) C++03 mode.
Clang's C++03 mode does not support delegating constructors.
Differential Revision: https://reviews.llvm.org/D104310
In typeinfo there is a reinterpret_cast between a uintptr_t and size_t. These are two integer types and therefore a reinterpret_cast is not right for this situation. It looks like it may have been copied and pasted from above in the file. An implicit cast works in it's place.
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D104814
Moves:
* `std::move`, `std::forward`, `std::declval`, and `std::swap` into
`__utility/${FUNCTION_NAME}`.
* `std::swap_ranges` and `std::iter_swap` into
`__algorithm/${FUNCTION_NAME}`
Differential Revision: https://reviews.llvm.org/D103734
Under the as-if rule, we can directly implement the array overload for
`std::swap`. By removing this circular dependency where `swap` is
implemented in terms of `swap_ranges` and `swap_ranges` is defined in
terms of `swap`, we can split them into their own headers. This will:
* limit the surface area in which Hyrum's law can bite us;
* force users to include the correct headers;
* make finding the definitions trivial (`swap` is a utility;
`swap_ranges` is an algorithm).
Differential Revision: https://reviews.llvm.org/D104760
Since we now have modules-enabled CI, it is now redundant to have ad-hoc
tests that check arbitrary things about our modules support. Instead,
the whole test suite should pass with modules enabled, period.
This patch also removes the module cache path workaround: one would
expect that modules work properly without that workaround. If that
isn't the case and we do run into flaky test failures, we can re-enable
the workaround temporarily (but that would be very vexing and we should
fix Clang ASAP if that's the case).
Differential Revision: https://reviews.llvm.org/D104746
* `<type_traits>` depends on `std::forward`, so we replaced it with
`static_cast<T&&>`.
* `swap`'s return type is confusing, so it's been rearranged to improve
readabilitiy.
* indicates whether work has been started or completed
* consolidates content that was split for dependency reasons (iff
everything has been merged)
* makes things a lot more fine-grained
* turns sub-CSVs into lists
* puts links into description section and removes patch column
* adds links to c++draft on occasion
These changes heavily prioritise the the reader of the generated HTML
file, not the source.
Differential Revision: https://reviews.llvm.org/D103295
C++03 didn't support `explicit` conversion operators;
but Clang's C++03 mode does, as an extension, so we can use it.
This lets us make the conversion explicit in `std::function` (even in '03),
and remove some silly metaprogramming in `std::basic_ios`.
Drive-by improvements to the tests for these operators, in addition
to making sure all these tests also run in `c++03` mode.
Differential Revision: https://reviews.llvm.org/D104682
The current implementation of `std::forward_list::swap` uses
`propagate_on_container_move_assignment` for `noexcept` specification.
This patch changes it to use `propagate_on_container_swap`, as it should.
Fixes https://llvm.org/PR50224.
Differential Revision: https://reviews.llvm.org/D101899
This is a fairly mechanical change, it just moves each algorithm into
its own header. This is intended to be a NFC.
This commit re-applies 7ed7d4ccb8, which was reverted in 692d7166f7
because the Modules build got broken. The modules build has now been
fixed, so we're re-committing this.
Differential Revision: https://reviews.llvm.org/D103583
Attribution note
----------------
I'm only committing this. This commit is a mix of D103583, D103330 and
D104171 authored by:
Co-authored-by: Christopher Di Bella <cjdb@google.com>
Co-authored-by: zoecarver <z.zoelec2@gmail.com>
P1518 does the following in C++23 but we'll just do it in C++17 as well:
- Stop requiring `Alloc` to be an allocator on some container-adaptor deduction guides
- Stop deducing from `Allocator` on some sequence container constructors
- Stop deducing from `Allocator` on some other container constructors (libc++ already did this)
The affected constructors are the "allocator-extended" versions of
constructors where the non-allocator arguments are already sufficient
to deduce the allocator type. For example,
std::pmr::vector<int> v1;
std::vector v2(v1, std::pmr::new_delete_resource());
std::stack s2(v1, std::pmr::new_delete_resource());
Differential Revision: https://reviews.llvm.org/D97742
When we removed the allocator<void> specialization, the triviality of
std::allocator<void> changed because the primary template had a
non-trivial default constructor and the specialization didn't
(so std::allocator<void> went from trivial to non-trivial).
This commit fixes that oversight by giving a trivial constructor to
the primary template when instantiated on cv-void.
This was reported in https://llvm.org/PR50299.
Differential Revision: https://reviews.llvm.org/D104398
A few slipped through the cracks because D104175 and D104170 didn't
concern themselves with newer commits.
Differential Revision: https://reviews.llvm.org/D104414
While the std::allocator<void> specialization was deprecated by
https://wg21.link/p0174#2.2, the *use* of std::allocator<void> by users
was not. The intent was that std::allocator<void> could still be used
in C++17 and C++20, but starting with C++20 (with the removal of the
specialization), std::allocator<void> would use the primary template.
That intent was called out in wg21.link/p0619r4#3.9.
As a result of this patch, _LIBCPP_ENABLE_CXX20_REMOVED_ALLOCATOR_MEMBERS
will also not control whether the explicit specialization is provided or
not. It shouldn't matter, since in C++20, one can simply use the primary
template.
Fixes http://llvm.org/PR50299
Differential Revision: https://reviews.llvm.org/D104323
Also, fix the last issue that prevented GCC 11 from passing the test
suite. Thanks to everyone else who fixed issues.
Differential Revision: https://reviews.llvm.org/D104315
This has been broken out of D104170 since it should be merged whether or
not we go ahead with the module map changes.
Differential Revision: https://reviews.llvm.org/D104175
https://eel.is/c++draft/atomics.types.operations#23 says: ... the value of failure is order except that a value of `memory_order::acq_rel` shall be replaced by the value `memory_order::acquire` and a value of `memory_order::release` shall be replaced by the value `memory_order::relaxed`.
This failure mapping is only handled for `_LIBCPP_HAS_GCC_ATOMIC_IMP`. We are seeing bad code generation for `compare_exchange_strong(cmp, 1, std::memory_order_acq_rel)` when using libc++ in place of libstdc++: https://godbolt.org/z/v3onrrq4G.
This was caught by tsan tests after D99434, `[TSAN] Honor failure memory orders in AtomicCAS`, but appears to be an issue in non-tsan code.
Reviewed By: ldionne, dvyukov
Differential Revision: https://reviews.llvm.org/D103846
The runtimes build has assertions enabled, which is necessary to catch
some of the modules-related issues we've been seeing recently. This
patch enables testing with modules in the runtimes build so as to cover
those cases.
In the future, a better solution would be to systematically use versions
of Clang that have assertions enabled. However, the Clangs we release
currently don't have assertions enabled by default, which causes a
challenge for the CI (we could try to build our own Clang from ToT with
assertions in the CI, but that poses some problems).
Differential Revision: https://reviews.llvm.org/D104252
This started as an attempt to fix a GCC 11 warning of misplaced parentheses.
I then noticed that trying to fix the parentheses warning actually triggered
errors in the tests, showing that we were incorrectly assuming that the
implementation of ranges::advance was using operator+= or operator-=.
This commit fixes that issue and makes the tests easier to follow by
localizing the assertions it makes.
Differential Revision: https://reviews.llvm.org/D103272
The synchronization library was marked as disabled on Apple platforms
up to now because we were not 100% sure that it was going to be ABI
stable. However, it's been some time since we shipped it in upstream
libc++ now and there's been no changes so far. This patch enables the
synchronization library on Apple platforms, and hence commits the ABI
stability as far as that vendor is concerned.
Differential Revision: https://reviews.llvm.org/D96790
Instead, people should be using CMAKE_POSITION_INDEPENDENT_CODE to control
whether they want to use PIC or not. We should try to avoid reinventing
the wheel whenever CMake natively supports something.
This makes libc++abi consistent with libc++ and libunwind.
Differential Revision: https://reviews.llvm.org/D103973
Makes the following operations constexpr:
* `std::swap(optional, optional)`
* `optional(optional<U> const&)`
* `optional(optional<U>&&)`
* `~optional()`
* `operator=(nullopt_t)`
* `operator=(U&&)`
* `operator=(optional<U> const&)`
* `operator=(optional<U>&&)`
* `emplace(Args&&...)`
* `emplace(initializer_list<U>, Args&&...)`
* `swap(optional&)`
* `reset()`
P2231 has been accepted by plenary, with the committee recommending
implementers retroactively apply to C++20. It's necessary for us to
implement _`semiregular-box`_ and _`non-propagating-cache`_, both of
which are required for ranges (otherwise we'll need to reimplement
`std::optional` with these members `constexpr`ified).
Differential Revision: https://reviews.llvm.org/D102119
The post-conditions for the self move assignment of `std::unique_ptr`
were changed. This requires no implementation changes. A test was added
to validate the new post-conditions.
Addresses
- LWG-3455: Incorrect Postconditions on `unique_ptr` move assignment
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D103764
The buffer size (`__nbuf`) in `num_put::do_put` is currently not an
integral/core constant expression. As a result, `__nar` is a Variable Length
Array (VLA). VLAs are a GNU extension and not part of the base C++ standard, so
unless there is good reason to do so they probably shouldn't be used in any of
the standard library headers. The call to `__iob.flags()` is the only thing
keeping `__nbuf` from being a compile time constant, so the solution here is to
simply err on the side of caution and always allocate a buffer large enough to
fit the base prefix.
Note that, while the base prefix for hex (`0x`) is slightly longer than the
base prefix for octal (`0`), this isn't a concern. The difference in the space
needed for the value portion of the string is enough to make up for this.
(Unless we're working with small, oddly sized types such as a hypothetical
`uint9_t`, the space needed for the value portion in octal is at least 1 more
than the space needed for the value portion in hex).
This PR also adds `constexpr` to `__nbuf` to enforce compile time const-ness
going forward.
Reviewed By: Mordante, #libc, Quuxplusone, ldionne
Differential Revision: https://reviews.llvm.org/D103558
This commit finishes moving the <atomic> design documents to the RST
documentation and removes the old documentation. https://libcxx.llvm.org
is already pointing to the new documentation only now, so the removal of
the old documentation is really a NFC.
I went over the old documentation and I don't think we're leaving anything
important behind - I think everything important was mentionned in the RST
documentation anyway.
Several macros were guarded with a check along the lines of:
#ifndef MACRO
# define MACRO ...
#endif
However, some of these macros are never intended to be defined by users,
so it's pointless to make this check (i.e. the first #ifndef is always
true). This commit removes those checks.
The motivation for doing this cleanup is to remove the impression that
arbitrary configurations macros can be defined by users when including
libc++ headers, which doesn't work reliably and leads to macro spaghetti.
If one needs to be able to override a knob in the __config, that's fine,
but the proper way to do that is to document the macro as being a public
facing knob in the documentation, and most likely to migrate that macro
to __config_site (depending on the nature of the macro).
Differential Revision: https://reviews.llvm.org/D103705
The "root nodes" of the graph are displayed in bold. My intent here
was to bold just the public-API headers, e.g. <vector> and
<experimental/coroutine> and <stdlib.h>, but not helper headers
such as <__functional_base> and <__iterator/next.h>. However,
the recent mass helper-header-ification has exposed defects in
this logic: all the new helpers were ending up bolded! Fix this.
Also, add <__undef_macros> to the list of headers we don't display
by default (like <__config>); it's not interesting to see those edges.
Also, add a sample `dot` command line to the `--help` text.
The `operator[]` of `_UnaryOp` and `_BinaryOp` returns the result of
calling `__op_`, so its return type should be `__result_type`, not
e.g. `_A0::value_type`. However, `_UnaryOp::value_type` also should
never have been `_A0::value_type`; it needs to be the correct type
for the result of the unary op, e.g. `bool` when the op is `logical_not`.
This turns out to matter when multiple operators are nested, e.g.
`+(v == v)` needs to have a `value_type` of `bool`, not `int`,
even when `v` is of type `valarray<int>`.
Differential Revision: https://reviews.llvm.org/D103416
This is a fairly mechanical change, it just moves each algorithm into its own header. This is a NFC.
Note: during this change, I burned down all the includes, so this follows "include only and exactly what you use."
Differential Revision: https://reviews.llvm.org/D103583
As discussed on cfe-dev [1], use the using_if_exists Clang attribute when
the compiler supports it. This makes it easier to port libc++ on top of
new platforms that don't fully support the C Standard library.
Previously, libc++ would fail to build when trying to import a missing
declaration in a <cXXXX> header. With the attribute, the declaration will
simply not be imported into namespace std, and hence it won't be available
for libc++ to use. In many cases, the declarations were *not* actually
required for libc++ to work (they were only surfaced for users to use
them as std::XXXX), so not importing them into namespace std is acceptable.
The same thing could be achieved by conscious usage of `#ifdef` along
with platform detection, however that quickly creates a maintenance
problem as libc++ is ported to new platforms. Furthermore, this problem
is exacerbated when mixed with vendor internal-only platforms, which can
lead to difficulties maintaining a downstream fork of the library.
For the time being, we only use the using_if_exists attribute when it
is supported. At some point in the future, we will start removing #ifdef
paths that are unnecessary when the attribute is supported, and folks
who need those #ifdef paths will be required to use a compiler that
supports the attribute.
[1]: http://lists.llvm.org/pipermail/cfe-dev/2020-June/066038.html
Differential Revision: https://reviews.llvm.org/D90257
If building code like this:
unsigned long val = 1000;
snprintf(buf, sizeof(buf), "%+lu", val);
with clang, clang warns
warning: flag '+' results in undefined behavior with 'u' conversion specifier [-Wformat]
Therefore, don't construct such undefined format strings. (There's
no compiler warnings here, as the compiler can't inspect dynamically
assembled format strings.)
This fixes number formatting in mingw-w64 if built with
`__USE_MINGW_ANSI_STDIO` defined (there, the '+' flag causes a
leading plus to be printed when formatting unsigned numbers too,
while the '+' flag doesn't cause any extra leading plus in other
stdio implementations).
Differential Revision: https://reviews.llvm.org/D103444
Most of our private headers need to be treated as submodules so that
Clang modules can export things correctly. Previous commits that split
monolithic headers into smaller chunks were unaware of this requirement,
and so this is being addressed in one fell swoop. Moving forward, most
new headers will need to have their own submodule (anything that's
conditionally included is exempt from this rule, which means `__support`
headers aren't made into submodules).
This hasn't been marked NFC, since I'm not 100% sure that's the case.
Differential Revision: https://reviews.llvm.org/D103551
D101613 added some macros used by Microsofts SAL. D103425 uses `__pre`
and `__post`. They are also used by SAL and cause issues when used on
Windows. Add them to the blacklist making it easier to figure out what
the issue is.
Differential Revision: https://reviews.llvm.org/D103541
Since D100581, Clang started flagging this variable which is set but
never read. Based on comparing this function with __match_at_start_posix_nosubs
(which is very similar), I am pretty confident that `__j` was simply left
behind as an oversight in Howard's 6afe8b0a23.
Also workaround some unused variable warnings in the <random> tests.
It's pretty lame that we're not asserting the skew and kurtosis of
the binomial and negative binomial distributions, but that should be
tackled separately.
Differential Revision: https://reviews.llvm.org/D103533
This matches the fact that we build the experimental library by default.
Otherwise, by default we'd be building the library but not testing it,
which is inconsistent.
Differential Revision: https://reviews.llvm.org/D102109
This reverts commit 924ea3bb53 *again*, this time because it broke the
LLDB build with modules. We need to figure out what's up with the libc++
modules build once and for all.
Differential Revision: https://reviews.llvm.org/D103369
In 07ef8e6796 and 3ed9f6ebde, `__nbuf` started to diverge from the amount
of space that was actually needed for the buffer. For 32-bit longs for example,
we allocate a buffer that is one larger than needed. Moreover, it is no longer
clear exactly where the extra +1 or +2 comes from - they're just numbers pulled
from thin air. This PR cleans up how `__nbuf` is calculated, and adds comments
to further clarify where each part comes from.
Specifically, it corrects the underestimation of the max size buffer needed
that the above two commits had to compensate for. The root cause looks to be
the use of signed type parameters to numeric_limits<>::digits. Since digits
only counts non-sign bits, the calculation was acting as though (for a signed
64-bit type) the longest value we would print was 2^63 in octal. However,
printing in octal treats values as unsigned, so it is actually 2^64. Thus,
using unsigned types and changing the final +2 to a +1 is probably a better
option.
Reviewed By: #libc, ldionne, Mordante
Differential Revision: https://reviews.llvm.org/D103339
The compiler used on Apple bots doesn't know about -std=c++20 yet, so
we can't use that just yet.
Differential Revision: https://reviews.llvm.org/D103475
The pipes.quote function quotes using single quotes, the same goes
for the newer shlex.quote (which is the preferred form in Python 3).
This isn't suitable for quoting in command lines on Windows (and the
documentation for shlex.quote even says it's only usable for Unix
shells).
In general, the python subprocess.list2cmdline function should do
proper quoting for the platform's current shell. However, it doesn't
quote the ';' char, which we pass within some arguments to run.py.
Therefore use the custom reimplementation from lit.TestRunner which
is amended to quote ';' too.
The fact that arguemnts were quoted with single quotes didn't matter
for command lines that were executed by either bash or the lit internal
shell, but if executing things directly using subprocess.call, as in
_supportsVerify, the quoted path to %{cxx} fails to be resolved by the
Windows shell.
This unlocks 114 tests that previously were skipped on Windows.
Differential Revision: https://reviews.llvm.org/D103310
Avoid including a header that is known not to work with clang in MSVC
mode when compiling as C.
(Alternatively, this could be something like "XFAIL: clang && msvc",
but I think it's more useful to actually check the rest of the test
instead of expecting the whole test to fail.)
Differential Revision: https://reviews.llvm.org/D103400
This was added inconsistently in
19fd9039ca242f408493b5c662f9d908eab8555e; Windows doesn't have the
aligned_alloc function (neither MSVC nor MinGW toolchains) and we don't
define _LIBCPP_HAS_ALIGNED_ALLOC while building libcxx.
Differential Revision: https://reviews.llvm.org/D103399
This define was out of sync with the corresponding define in tests, it
was added inconsistently in 171c77b7da.
Modern MSVC environments do have these typedefs and functions.
Differential Revision: https://reviews.llvm.org/D103398
While the code uses the type name `std::mbstate_t`, the warning message
mentions the original underlying type, which is a C library internal
type name.
On Windows this type is called `_Mbstatet` instead of `__mbstate_t`. Use
expect-warning-re to avoid spelling out the literal name of the type.
Due to issues with the detection of the clang-verify feature, these
tests have been skipped in the Windows CI configuration so far.
Differential Revision: https://reviews.llvm.org/D103309
Make sure we provide the correct It::difference_type member and update
the tests and synopses to be accurate.
Supersedes D102657 and D103101 (thanks to the original authors).
Differential Revision: https://reviews.llvm.org/D103273
Give each of the relevant functional operators a `__result_type`
instead, so that we can keep using those typedefs in <valarray>
even when the public binder typedefs are removed in C++20.
Differential Revision: https://reviews.llvm.org/D103371
Due to issues with the detection of the clang-verify feature, these
tests have been skipped in the Windows CI configuration so far.
Differential Revision: https://reviews.llvm.org/D103308
It looks to me as if *every* helper header needs to be added to the modulemap,
actually; which is unfortunate since we keep proliferating them at such a
rapid pace.
This should have been done in D96385; thanks ldionne for the catch!
Also, make the back/front inserter behavior tests a little more thorough,
which incidentally caught a cut-and-paste-bug in `nasty_list`, so fix that.
Differential Revision: https://reviews.llvm.org/D103318
C++17 deprecated std::iterator and removed it as a base class for all
iterator adaptors. We implement that change, but we still provide a way
to inherit from std::iterator in the few cases where doing otherwise
would be an ABI break.
Supersedes D101729 and the std::iterator base parts of D103101 and D102657.
Differential Revision: https://reviews.llvm.org/D103171
Implements part of P0896 'The One Ranges Proposal'.
Implements [range.iter.op.prev].
Depends on D102563.
Differential Revision: https://reviews.llvm.org/D102564
Implements part of P0896 'The One Ranges Proposal'.
Implements [range.iter.op.next].
Depends on D101922.
Differential Revision: https://reviews.llvm.org/D102563
Ensures that `get_return_object`'s return type is the same as the return type for the function calling `co_return`. Otherwise, we try to construct an object, then free it, then return it.
Differential Revision: https://reviews.llvm.org/D103196
I'm adding the job as a soft-fail for now, but once all the tests have
been fixed to work on it, we'll switch over from GCC 10 to GCC 11 and
remove the soft-fail.
Differential Revision: https://reviews.llvm.org/D103116
This prevents std::format to be available until there's an ABI stable
version. (This only impacts the Apple platform.)
Depends on D102703
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D102705
This is a preparation to split the format header in smaller parts for the
upcoming patches.
Depends on D101723
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D102703
This also provides some of the scaffolding needed by D102992 and D101729, and mops up after D101730 etc.
Differential Revision: https://reviews.llvm.org/D103055
If the nested create_directory call fails, we'd still want to
re-report the errors with the create_directories function name,
which is what the caller called.
This fixes one aspect from MS STL's tests for std::filesystem.
Differential Revision: https://reviews.llvm.org/D102365
This particular test relies on internal details from the libc++
filesystem implementation header, and those details are structured
differently in the implementation for Windows.
Differential Revision: https://reviews.llvm.org/D102357
Use the same visiblity attributes as for all other template
specializations in the same file; declare the specialization itself
using _LIBCPP_TYPE_VIS, and don't use _LIBCPP_EXPORTED_FROM_ABI on
the destructor. Methods that are excluded from the ABI are marked
with _LIBCPP_INLINE_VISIBILITY.
This makes the vtable exported from DLL builds of libc++. Practically,
it doesn't make any difference for the CI configuration, but it
can make a difference in mingw setups.
Differential Revision: https://reviews.llvm.org/D102717
cxx20_iterator_traits.compile.pass.cpp actually depends on
implementation details of libc++, which is not great;
but I just left a comment and moved on.
Not only do we conscientiously avoid using `__wrap_iter` for non-contiguous
iterators (in vector, string, span...) but also we make the assumption
(in regex) that `__wrap_iter<_Iter>` is contiguous for all `_Iter`.
So `__wrap_iter<reverse_iterator<int*>>` should be considered IFNDR,
and every `__wrap_iter` should correctly advertise contiguity in C++20.
Drive-by simplify some type traits.
Reviewed as part of https://reviews.llvm.org/D102781
- Fixes paper number P1862 -> P1868. (The title was correct.)
- Marks P1868 as in progress.
- Marks P1892 as in progress.
- Marks LWG-3327 as nothing to do, since the wording change doesn't
impact the code. (Also updated on the general C++20 status page.)
This commit alphabetizes all includes in libcxx. This is a NFC.
This can also serve as a pseudo "announcement" for how we should order these headers going forward (note: double underscores go before other headers).
Differential Revision: https://reviews.llvm.org/D102941
This is the second to last one! Based on D101396. Depends on D100255. Refs D101079 and D101193.
Differential Revision: https://reviews.llvm.org/D101476
Eventually, this should become the default way of running the tests.
For now, only move a few CI nodes to it, and keep a node that runs the
legacy configuration.
Differential Revision: https://reviews.llvm.org/D97565
* adds `sized_range` and conformance tests
* moves `disable_sized_range` into namespace `std::ranges`
* removes explicit type parameter
Implements part of P0896 'The One Ranges Proposal'.
Differential Revision: https://reviews.llvm.org/D102434
Add this attribute to some types to ensure that they have
debug info.
The debug info for these classes are required for debuggers to display
some STL types. With constructor homing (a new debug info optimization)
their debug info isn't emitted because their constructors are never
called.
The list of types with the attribute added are __hash_value_type,
__value_type, __tree_node_base, __tree_node, __hash_node, __list_node,
and __forward_list_node.
Differential Revision: https://reviews.llvm.org/D98750
Fix __bitop_unsigned_integer and rename to __libcpp_is_unsigned_integer.
There are only five unsigned integer types, so we should just list them out.
Also provide `__libcpp_is_signed_integer`, even though the Standard doesn't
consume that trait anywhere yet.
Notice that `concept uniform_random_bit_generator` is specifically specified
to rely on `concept unsigned_integral` and *not* `__is_unsigned_integer`.
Instantiating `std::ranges::sample` with a type `U` satisfying
`uniform_random_bit_generator` where `unsigned_integral<U::result_type>`
and not `__is_unsigned_integer<U::result_type>` is simply IFNDR.
Orthogonally, fix an undefined behavior in std::countr_zero(__uint128_t).
Orthogonally, improve tests for the <bit> manipulation functions.
It was these new tests that detected the bug in countr_zero.
Differential Revision: https://reviews.llvm.org/D102328
The problem with debug mode tests is that it isn't known which particular
_LIBCPP_ASSERT causes the test to exit, and as shown by
https://reviews.llvm.org/D100029 and 2908eb20ba it might be not the
expected one.
The patch adds TEST_LIBCPP_ASSERT_FAILURE macro that allows checking
_LIBCPP_ASSERT message to ensure we caught an expected failure.
Reviewed By: Quuxplusone, ldionne
Differential Revision: https://reviews.llvm.org/D100595
Adds MAKE_CSTRING and makes the operators of `MultiStringType` `constexpr`.
The code is copied from D96664 so it can be used in D80895.
Differential Revision: https://reviews.llvm.org/D102414
On windows, the native path char type is wchar_t - therefore, this test
didn't actually do the conversion that the test was supposed to exercise.
The charset conversions on windows do cause extra allocations outside of
the provided allocator though, so that bit of the test has to be waived
now that the test actually does something. (Other tests have similar
TEST_NOT_WIN32() for allocation checks for charset conversions.)
Also fix a typo, and amend the path.native.obs/string_alloc test to
test char8_t, too.
Differential Revision: https://reviews.llvm.org/D102360
Before this commit, we'd get a compilation error because the operator() overload was ambiguous.
Differential Revision: https://reviews.llvm.org/D102263
D85051's honeypot solution was a bit too aggressive swallowed up the
comparison types, which made comparing objects of different ordering
types ambiguous.
Depends on D101707.
Differential Revision: https://reviews.llvm.org/D101708
Don't use stat and lstat on Windows; lstat is missing, stat only provides
the modification times with second granularity (and does the wrong thing
regarding symlinks). Instead do a minimal reimplementation using the
native windows APIs.
Differential Revision: https://reviews.llvm.org/D101731
Both `<type_traits>` and `<charconv>` implemented this function with
different names and a slightly different behavior. This removes the
version in `<charconv>` and improves the version in `<typetraits>`.
- The code can be used again in C++11.
- The original claimed C++14 support, but `[[nodiscard]]` is not
available in C++14.
- Adds `_LIBCPP_INLINE_VISIBILITY`.
Reviewed By: zoecarver, #libc, Quuxplusone
Differential Revision: https://reviews.llvm.org/D102332
On Windows, the permission bits are mapped down to essentially only
two possible states; readonly or readwrite. Normalize the checked
permission bitmask to match what the implementation will return.
Differential Revision: https://reviews.llvm.org/D101728
For some reason clang-10 can't match the expected errors produced by
passing icomplete arrays to range access functions. Disabling the tests
is a stop-gap solution to fix the bots.
Turn this test into a normal mode as it contains well-formed code and
checks for defined behavior. It still can be run in debug mode as of D100866.
Differential Revision: https://reviews.llvm.org/D102192
C++17 deprecates `std::raw_storage_iterator` and C++20 removes it.
Implements part of:
* P0174R2 'Deprecating Vestigial Library Parts in C++17'
* P0619R4 'Reviewing Deprecated Facilities of C++17 for C++20'
Differential Revision: https://reviews.llvm.org/D101730
The standard leaves it up to the implementation to decide whether or not
these operators are hidden friends. There are several (well-documented)
reasons to prefer hidden friends, as well as an argument for improved
readability.
Depends on D100342.
Differential Revision: https://reviews.llvm.org/D101707
* `operator!=` isn't in the spec
* `<compare>` is designed to work with `operator<=>` so it doesn't
really make sense to have `operator<=>`-less friendly sections.
Depends on D100283.
Differential Revision: https://reviews.llvm.org/D100342
`weak_equality` and `strong_equality` were removed before being
standardised, and need to be removed.
Also adjusts `common_comparison_category` since its test needed
adjusting due to the equality deletions.
Differential Revision: https://reviews.llvm.org/D100283
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.
Louis Dionne