In basic_string and vector, we've been encapsulating all exception
throwing code paths in helper functions of a base class, which are defined
in the compiled library. For example, __vector_base_common defines two
methods, __throw_length_error() and __throw_out_of_range(), and the class
is externally instantiated in the library. This was done a long time ago,
but after investigating, I believe the goal of the current design was to:
1. Encapsulate the code to throw an exception (which is non-trivial) in
an externally-defined function so that the important code paths that
call it (e.g. vector::at) are free from that code. Basically, the
intent is for the "hot" code path to contain a single conditional jump
(based on checking the error condition) to an externally-defined function,
which handles all the exception-throwing business.
2. Avoid defining this exception-throwing function once per instantiation
of the class template. In other words, we want a single copy of
__throw_length_error even if we have vector<int>, vector<char>, etc.
3. Encapsulate the passing of the container-specific string (i.e. "vector"
and "basic_string") to the underlying exception-throwing function
so that object files don't contain those duplicated string literals.
For example, we'd like to have a single "vector" string literal for
passing to `std::__throw_length_error` in the library, instead of
having one per translation unit.
However, the way this is achieved right now has two problems:
- Using a base class and exporting it is really weird - I've been confused
about this ever since I first saw it. It's just a really unusual way of
achieving the above goals. Also, it's made even worse by the fact that
the definitions of __throw_length_error and __throw_out_of_range appear
in the headers despite always being intended to be defined in the compiled
library (via the extern template instantiation).
- We end up exporting those functions as weak symbols, which isn't great
for load times. Instead, it would be better to export those as strong
symbols from the library.
This patch fixes those issues while retaining ABI compatibility (e.g. we
still export the exact same symbols as before). Note that we need to
keep the base classes as-is to avoid breaking the ABI of someone who
might inherit from std::basic_string or std::vector.
Differential Revision: https://reviews.llvm.org/D111173
This is less brittle than hand-picking the substitutions that we
pass to the test, since a config could theorically use non-base
substitutions as well (such as defining %{flags} in terms of another
substitution like %{include}).
Also, print the decoded substitutions, which makes it much easier
to debug the test when it fails.
Differential Revision: https://reviews.llvm.org/D111179
Some tests repeat the definition of `DELETE_FUNCTION` macro locally.
However, it's not even requred to guard against in the C++03 case since
Clang supports `= delete;` in C++03 mode. A warning is issued but
`libc++` tests run with `-Wno-c++11-extensions`, so this isn't an issue.
Since we don't support other compilers in C++03 mode, `= delete;` is
always available for use. As such, inline all calls of `DELETE_FUNCTION`
to use `= delete;`.
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D111148
This was missed in ec574f5da4. TIME_UTC
is a define that goes along with timespec_get. The testcase that it is
moved to is only run for >= C++17, so the surrounding ifdef guard
can be dropped.
Differential Revision: https://reviews.llvm.org/D110988
e9ee517930 added support for using
winpthreads on Windows, enabled if `__WINPTHREADS_VERSION` was
defined (i.e. if winpthreads headers have been included before
including libcxx `__config`). This was fragile (libcxx changed
behaviour depending on what headers had been included externally
before), and was changed in a1bc823a59
to use pthreads on Windows whenever the pthread.h header was
available.
This is also fragile; pthread.h might be unavailable while building
libcxx but installed later, and available when users include the
libcxx headers.
In practice, in every modern setup for building libcxx for Windows
I've seen, users end up manually configuring it with
`LIBCXX_HAS_WIN32_THREAD_API=ON`, as the users may have winpthreads
installed (for other libraries/projects to use) while wanting to
build libcxx with the default win32 threading.
Don't automatically pick up pthreads on Windows even if the header
is available. Instead require the user to configure the libcxx
build with `LIBCXX_HAS_PTHREAD_API=ON` if that's desired.
Differential Revision: https://reviews.llvm.org/D110975
This is to simplify an upcoming change where we distinguish between
flavors of libc++ by adding an apple-libc++ Lit feature.
Differential Revision: https://reviews.llvm.org/D110870
The existing tests for transform_view::iterator weren't quite right,
and can be simplified now that we have more of C++20 available to us.
Having done that, let's use the same pattern for iota_view::iterator
as well.
Differential Revision: https://reviews.llvm.org/D110774
This adds the width estimation functions to the std-format-spec.
Implements parts of:
- P0645 Text Formatting
- P1868 width: clarifying units of width and precision in std::format
Reviewed By: #libc, ldionne, vitaut
Differential Revision: https://reviews.llvm.org/D103413
Seems this section is not updated since we have transited to llvm-project monorepo.
At the start, we build libcxx under monorepo configuration but later try to make the separate configuration for libcxx build
and running benchmark.
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D110722
This reverts part of commit b82683b2eb.
I hadn't intended to remove the `// -*- C++ -*-` comment line
from `libcxx/include/version`, only from the generated tests.
Thanks to Raul Tambre for the catch.
Even if these comments have a benefit in .h files (for editors that
care about language but can't be configured to treat .h as C++ code),
they certainly have no benefit for files with the .cpp extension.
Discussed in D110794.
Even if these comments have a benefit in .h files (for editors that
care about language but can't be configured to treat .h as C++ code),
they certainly have no benefit for files with the .cpp extension.
Discussed in D110794.
This reverts commit 9f641c96cb.
The "python" command in gdb uses the python gdb is linked to,
not what "python" would give you if you used it directly in the shell.
As of e9564c3698, libcxx/gdb/gdb_pretty_printer_test.sh.cpp
fails locally for me because the REQUIRES check for host-has-gdb-with-python
uses python, which for me expands to python 2.7.18. This failure does not seem
to be caught on any upstream builders, potentially because they don't have gdb,
python, or a version of python that makes the test UNSUPPORTED (like python3).
This updates the check to use the python specified by the build (which should
be the python that runs this code), rather than just python.
Differential Revision: https://reviews.llvm.org/D110887
Apple's libc++ has a few differences with the LLVM libc++, and it is
necessary to use a custom configuration file to test it properly.
Differential Revision: https://reviews.llvm.org/D110777
To reduce confusion, this commit makes sure that the name of the testing
configurations match the convention used for the stdlib= Lit parameter,
since those effectively correspond to each other.
Vendors take libc++ and ship it in various ways. Some vendors might
ship it differently from what upstream LLVM does, i.e. the install
location might be different, some ABI properties might differ, etc.
In the past few years, I've come across several instances where
having a place to test some of these properties would have been
incredibly useful. I also just got bitten by the lack of tests
of that kind, so I'm adding some now.
The tests added by this commit for Apple platforms have numerous
TODOs that capture discrepancies between the upstream LLVM CMake
and the slightly-modified build we perform internally to produce
Apple's system libc++. In the future, the goal would be to upstream
all those differences so that it's possible to build a faithful
Apple system libc++ with the upstream LLVM sources only.
But this isn't only useful for Apple - this lays out the path for
any vendor being able to add their own checks (either upstream or
downstream) to libc++.
Differential Revision: https://reviews.llvm.org/D110736
The Runtimes build is by far our longest CI configuration, so it makes
sense to run it earlier during CI. For consistency, move all the other
jobs from that "section" too.
Some of these were previously half-implemented in "ordering.h";
now they're all implemented, and tested.
Note that `constexpr` functions are implicitly `inline`, so the
standard wording omits `inline` on these; but Louis and I agree
that that's surprising and it's better to be explicit about it.
Differential Revision: https://reviews.llvm.org/D110515
Instead of using a base class to store the members and the optional
size, use [[no_unique_address]] to achieve the same thing without
needing a base class.
Also, as a fly-by:
- Change subrange from struct to class (per the standard)
- Improve the diagnostic for when one doesn't provide a size to the ctor of a sized subrange
- Replace this->member by just member since it's not in a dependent base anymore
This change would be an ABI break due to [[no_unique_address]], but we
haven't shipped ranges anywhere yet, so this shouldn't affect anyone.
Differential Revision: https://reviews.llvm.org/D110370
Before this patch, we had features named 'libc++', 'libstdc++' and
'msvc' to describe the three implementations that use our test suite.
This patch renames them to 'stdlib=libc++', 'stdlib=libstdc++', etc
to avoid confusion between MSVC's STL and the MSVC compiler (or Clang
in MSVC mode).
Furthermore, this prepares the terrain for adding support for additional
"implementations" to the test suite. Basically, I'd like to be able to
treat Apple's libc++ differently from LLVM's libc++ for the purpose of
testing, because those effectively behave in different ways in some aspects.
There's really no reason to even have two different enums here,
but *definitely* we shouldn't have *three*, and they don't need
so many synonymous enumerator values.
Differential Revision: https://reviews.llvm.org/D110516
In reaction to the issues raised by Richard in https://llvm.org/D109066,
this commit does not apply P1951 as a DR in previous standard modes,
since it breaks valid code.
I do believe it should be applied as a DR, however ideally we'd get some
sort of statement from the Committee to this effect (and all implementations
would behave consistently). In the meantime, only implement P1951 starting
with C++23 -- we can always come back and apply it as a DR if that's what
the Committee says.
Differential Revision: https://reviews.llvm.org/D110347
Changes the style as requested by @ldionne in D103368.
Reviewed By: ldionne, #libc, Quuxplusone
Differential Revision: https://reviews.llvm.org/D109835
Louis Dionne