In order to test the LLDB data formatters make is required and SWIG
needs to be updated to version 4.
As drive-by, this patch sorts the entries and removes some duplicates.
Adds the sys_info class and time_zone::get_info(). The code still has a
few quirks and has not been optimized for performance yet.
The returned sys_info is compared against the output of the zdump tool
in the test giving confidence the implementation is correct.
Implements parts of:
- P0355 Extending <chrono> to Calendars and Time Zones
Implements:
- LWGXXXX The sys_info range should be affected by save
The OSS fuzz build has been broken for a while because of changes
to the cmake configuration. This patch fixes the issues by defaulting to
libunwind as the default runtime
The documentation mentions manually pushing Docker images to the CI. The
preferred way is to use the proper GitHub action. This updates the
documentation.
---------
Co-authored-by: Will Hawkins <whh8b@obs.cr>
This uses the macro on record types and inline constexpr variables. The
tagged declarations are very likely to change in future versions of
libc++:
- __fields are internal types used to control the formatter's parse
functions which fields to expect. Newer formatters may add new fields.
For example the filesystem::path formatter accepted in the recent Tokyo
meeting added a new 'g' flag, which differs from the 'g' type.
- The Unicode tables. The number of entries in these table likely differ
between Unicode versions. The tables contain only a part of all Unicode
properties. Typically they are stored in a 32-bit entry where some bits
contain the properties and other bits the size of the range. Changes in
the Unicode or C++ algorithms may require more properties to be
available in C++. This may affect the number of bits available in the
range. If needed, other declarations get the macro. This is mainly a
first time to review this approach.
This was originally https://reviews.llvm.org/D143494 where a new macro
_LIBCPP_HIDE_FROM_ABI_TYPE was defined. Testing revealed the existing
macro _LIBCPP_HIDE_FROM_ABI could be used. The "parts" of the macro that
do not affect records are not harmful. Based on this information the
existing macro was used and additional documentation was written.
On Windows you can not create symlinks without elevated privileges
unless you have Windows developer mode enabled. There's ~67 libcxx tests
that run into failures on windows if your environment is not set up
correctly (Go to windows settings and enable "developer mode").
This change:
- Adds a feature check for whether the host can create symlinks. (see
libcxx/utils/libcxx/test/features.py)
- Mark the feature as required for the 67 tests that hit failures on
windows due to this. This will allow lit to correctly mark these tests
as unsupported instead of unexpectedly failed (this is helpful since
then you know you didn't break something with your change, it's just
that it's not supported with your environment).
The `128-bit-atomics` libcxx feature is incorrectly named because tests
that are Xfailed with it is really using `int[128]`. Additionally,
because toolchain support for that feature is determined based on a much
smaller size (`char[16]`), tests would execute incorrectly without
required toolchain support.
So, rename `128-bit-atomics` as `1024-bit-atomics`, and use an
appropriate type to check for the presence of the feature.
The current selection is done in the test scripts which gives the user
no control where to find clang-tidy. The version selection itself is
hard-coded and not based on the version of clang used.
This moves the selection to configuration time and tries to find a
better match.
- Mixing the version of clang-tidy and the clang libraries causes ODR
violations. This results in practice in crashes or incorrect results.
- Mixing the version of clang-tidy and the clang binary sometimes causes
issues with supported diagnostic flags. For example, flags tested
against clang 17 may not be available in clang-tidy 16.
Currently clang-tidy 18.1 can be used, it tests against the clang
libraries version 18. This is caused by the new LLVM version numbering
scheme.
The new selection tries to match the clang version or the version of the
HEAD and the last 3 releases. (During the release period libc++ supports
4 versions instead of the typical 3 versions.)
Yesterday, one of the issues the libc++ builders encountered was that
they were using a client that was too old; too old to even update
automatically.
To get things working, i had to push a testing image with this change.
The testing image has been working for 12 hours now, so it's time to
commit to it :-)
We forward declare `reference_wrapper` in multiple places already. This
moves the declaration to the canonical place and removes unnecessary
includes of `__functional/reference_wrapper.h`.
Originally, we used __libcpp_verbose_abort to handle assertion failures.
That function was declared from all public headers. Since we don't use
that mechanism anymore, we don't need to declare __libcpp_verbose_abort
from all public headers, and we can clean up a lot of unnecessary
includes.
This patch also moves the definition of the various assertion categories
to the <__assert> header, since we now rely on regular IWYU for these
assertion macros.
rdar://105510916
On Windows the libc++ test suite sees the MSVC STL headers and may
conclude these are libc++ headers when inspecting the name. Modules
guard against forgetting to export new headers. Finding MSVC STL's
headers gives false positives. Since the CI tests non-Windows platforms
too, the validation will be disabled on Windows.
Fixes: https://github.com/llvm/llvm-project/issues/79010
---------
Co-authored-by: Louis Dionne <ldionne.2@gmail.com>
Some changes in libc++ affect the dylib. These changes are not present
on systems that use the system dylib. Currently that are the Apple
backdeployment targets. Figuring out which MacOS versions to target is
not trivial for non-Apple engineers. These shorthands make it easier to
select the proper feature make a test UNSUPPORTED or XFAIL.
During the design discussion with Louis we considered whether or not to
add preprocessor definitions to allow partial disabling of a test. This
would be useful when an existing feature is changed by modifying the
dylib. In the end we decided not to add this feature to avoid additional
complexity in the tests. Instead the test will be disabled for that
target.
We noticed that some feature-test macros were not conditional on
configuration flags like _LIBCPP_HAS_NO_FILESYSTEM. As a result, code
attempting to use FTMs would not work as intended.
This patch adds conditionals for a few feature-test macros, but more
issues may exist.
rdar://122020466
`non-lockfree-atomics` is very similar to `has-64-bit-atomics`; to
simplify, we can have uniform features for atomic types of
increasing sizes (`has-128-bit-atomics`, `has-256-bit-atomics`, etc.).
`is-lockfree-runtime-function` feature was a workaround for the partial
support for large atomic types on older versions of macOS (see
https://reviews.llvm.org/D91911). While we still support macOS 10.14,
conceptually it's simpler to check for support for all the atomic
functionality inside the `has-*-atomics` features, and the workaround is
no longer worth the maintenance cost.
The <__threading_support> header is a huge beast and it's really
difficult to navigate. I find myself struggling to find what I want
every time I have to open it, and I've been considering splitting it up
for years for that reason.
This patch aims not to contain any functional change. The various
implementations of the threading base are simply moved to separate
headers and then the individual headers are simplified in mechanical
ways. For example, we used to have redundant declarations of all the
functions at the top of `__threading_support`, and those are removed
since they are not needed anymore. The various #ifdefs are also
simplified and removed when they become unnecessary.
Finally, this patch adds documentation for the API we expect from any
threading implementation.
This reverts commit 7d9b5aa65b since
std/utilities/format/format.arguments/format.arg/visit.return_type.pass.cpp
is failing on Windows when building with Clang-cl.
Revert "Revert #76246 and #76083"
This reverts commit 5c150e7eeb.
Adds a small fix that should properly disable the tests on Windows.
Unfortunately the original poster has not provided feedback and the
original patch did not fail in the LLVM CI infrastructure.
Modules are known to fail on Windows due to non compliance of the
C library. Currently not having this patch prevents testing on other
platforms.
