Libc++'s policy is to support only the latest released Xcode, which is
Xcode 16.x. We did update our CI jobs to Xcode 16.x, but we forgot to
update the documentation, which still mentioned Xcode 15. This patch
updates the documentation and cleans up outdated mentions of
apple-clang-15 in the test suite.
By far the most important part of this patch is updating
GettingInvolved.rst to include the invite link, but I've grepped for any
other discord.com links.
I'm no Discord expert, but from my experience (confirmed via @preames
kindly testing as well) the direct channel links provide a confusing
experience if you haven't already found and used an invite link to the
LLVM Discord server. If you're logged into Discord but not a member of
LLVM's sever, the web app opens and then...nothing. No channel opens, no
prompt to join the server or even a hint that you need to find an invite
link (and if you're not used to Discord, you likely don't even know
that's necessary).
This patch addresses the issue by providing the invite link where
Discord is mentioned.
We have a buch of coding guidelines which are either documented as
design docs, which aren't really applicable or not at all. This moves
coding guidelines we have currently in the design docs into a separate
file and adds a bunch of guidelines which we have but aren't documented
anywhere.
Instead of tracking those using our static CSV files, I created lists of
subtasks in their respective issues (#99939 and #105169) to track the
work that is still left.
This patch removes obsolete status pages for projects that were
completed: LLVM 18 release, C++20 Ranges and Spaceship support.
Co-authored-by: Hristo Hristov <zingam@outlook.com>
- Landing page: add link to the libc++ Discord channel
- Landing page: reorder "Getting Involved" above "Design documents"
- Landing page: remove "Notes and Known Issues" which was completely outdated
- Rename "Using Libc++" to "User Documentation" and update contents
- Rename "Building Libc++" to "Vendor Documentation" and update contents
The "BuildingLibcxx" and "UsingLibcxx" pages have basically been used for
vendor and user documentation respectively. However, they were named in
a way that doesn't really make that clear. Renaming the pages now gives
us a location to clearly document what we target at vendors and what we
target at users, and to do that separately.
We already documented that libc++ was C++14 complete, but we still
documented the status of C++14. Since that is redundant (and I suspect
the C++14 status page was missing some stuff), simply remove them.
Implementing the Hermite polynomials which are part of C++17's
mathematical special functions. The goal is to get early feedback which
will make implementing the other functions easier. Integration of
functions in chunks (e.g. `std::hermite` at first, then `std::laguerre`,
etc.) might make sense as well (also see note on boost.math below).
I started out from this abandoned merge request:
https://reviews.llvm.org/D58876 .
The C++23 standard defines them in-terms of `/* floating-point type */`
arguments. I have not looked into that.
Note, there is still an ongoing discussion on discourse whether
importing boost.math is an option.
GCC 14 has been released a while ago. We've updated the CI to use GCC 14
now. This removes any old annotations in the tests and updates the
documentation to reflect the updated version requirements.
Since we have released Clang 16 is no longer actively supported. However
the FreeBSD runner is still using this, so some tests still guard
against Clang 16.
The section discusses the reasons for the libraries inception more than
a decade ago. Now it discusses the progess libc++ has made, and the many
impressive acomplishments our contributors have brought it.
The initial section remains below.
---------
Co-authored-by: Louis Dionne <ldionne.2@gmail.com>
We've been applying ``[[nodiscard]]`` more liberally recently, but we
don't have any documented guidance on when it's correct to add it. This
patch adds that guidance. Follow-up patches will gradually apply it to
the code base.
In LLVM 17, we switched to numbered RST files for release notes, which
makes it easier to deal with cherry-picks around release points. However,
we stopped publishing `libcxx/docs/ReleaseNotes.html`, which was
referenced by external sites.
This patch ensures that we keep publishing `ReleaseNotes.html` by simply
including the versioned RST file in the unversioned RST file.
Fixes#77955
The old notes are kept to make it easier to backport changes to the
release branch. There are no LLVM-17 releases expected and this
documentation should not be available in the LLVM-18 release.
Note after branching LLVM-18 both LLVM-18 and LLVM-19 release notes
should be available.
GCC 13 is the latest GCC release and tested in the libc++ CI for several
month. According to our policy we only support the latest version,
update the documentation to the latest version.
The current CI badge is currently in libc++ documentation. This does not
seem the right place:
- The typical location on GitHub is on the main README.
- The documentation is shipped as part of the release:
- This link does not work in off-line mode. Currently our documentation
works in off-line mode.
- The status in the release documentation does not reflect the status of
the shipped library. So users looking at it may see a red status and get
confused.
This moves the badge to the README.
This patch actually runs the tests for picolibc behind an emulator,
removing a few workarounds and increasing coverage.
Differential Revision: https://reviews.llvm.org/D155521
Picolibc is a C Standard Library that is commonly used in embedded
environments. This patch adds initial support for this configuration
along with pre-commit CI. As of this patch, the test suite only builds
the tests and nothing is run. A follow-up patch will make the test suite
actually run the tests.
Differential Revision: https://reviews.llvm.org/D154246
According to https://developer.apple.com/support/xcode/, quite a few of
our availability macros don't do anything anymore, so we might as well
remove them to clean up the code a bit.
I could probably break this commit into more pieces.
---
This patch adds libc++ support for Android L (Android 5.0+) and up,
tested using the Android team's current compiler, a recent version of
the AOSP sysroot, and the x86[-64] Android Emulator.
CMake and Lit Configuration:
Add runtimes/cmake/android/Arch-${ARCH}.cmake files that configure CMake
to cross-compile to Android without using CMake's built-in NDK support
(which only works with an actual packaged NDK).
Add libcxx/cmake/caches/AndroidNDK.cmake that builds and tests libc++
(and libc++abi) for Android. This file configures libc++ to match what
the NDK distributes, e.g.:
- libc++_shared.so (includes libc++abi objects, there is no
libc++abi.so). libunwind is linked statically but not exported.
- libc++_static.a (does not include libc++abi) and libc++abi.a
- `std::__ndk1` namespace
- All the libraries are built with `__ANDROID_API__=21`, even when they
are linked to something targeting a higher API level.
(However, when the Android LLVM team builds these components, they do
not use these CMake cache files. Instead they use Python scripts to
configure the builds. See
https://android.googlesource.com/toolchain/llvm_android/.)
Add llvm-libc++[abi].android-ndk.cfg.in files that test the Android
NDK's libc++_shared.so. These files can target old or new Android
devices. The Android LLVM team uses these test files to test libc++ for
both arm/arm64 and x86/x86_64 architectures.
The Android testing mode works by setting %{executor} to adb_run.py,
which uses `adb push` and `adb shell` to run tests remotely. adb_run.py
always runs tests as the "shell" user even on an old emulator where "adb
unroot" doesn't work. The script has workarounds for old Android
devices. The script uses a Unix domain socket on the host
(--job-limit-socket) to restrict concurrent adb invocations. Compiling
the tests is a major part of libc++ testing run-time, so it's desirable
to exploit all the host cores without overburdening the test devices,
which can have far fewer cores.
BuildKite CI:
Add a builder to run-buildbot, `android-ndk-*`, that uses Android Clang
and an Android sysroot to build libc++, then starts an Android emulator
container to run tests.
Run the emulator and an adb server in a separate Docker container
(libcxx-ci-android-emulator), and create a separate Docker image for
each emulator OS system image. Set ADB_SERVER_SOCKET to connect to the
container's adb server. Running the only adb server inside the container
makes cleanup more reliable between test runs, e.g. the adb client
doesn't create a `~/.android` directory and the adb server can be
restarted along with the emulator using docker stop/run. (N.B. The
emulator insists on connecting to an adb server and will start one
itself if it can't connect to one.)
The suffix to the android-ndk-* job is a label that concisely specifies
an Android SDK emulator image. e.g.:
- "system-images;android-21;default;x86" ==> 21-def-x86
- "system-images;android-33;google_apis;x86_64" ==> 33-goog-x86_64
Fixes: https://github.com/llvm/llvm-project/issues/69270
Differential Revision: https://reviews.llvm.org/D139147
Since LLVM 17 has been branched and is on the verge of being released,
we can drop the CI job that tests against Clang 15. I think the number
of cherry-picks to `release/17.x` will be a lot smaller now, so keeping
a Clang 15 job around for that purpose seems unnecessary.
As a fly-by, this patch also removes some Clang 15 workarounds and test
suite annotations as we usually do. It also removes some slightly older
gcc test suite annotations that were missed.
AppleClang 15 was released on September 18th and is now stable. Per our
policy, we're bumping the supported AppleClang compiler to the latest
release. This allows cleaning up the test suite, but most importantly
unblocking various other patches that are blocked on bumping the
compiler requirements.
This is the first step to implement time zone support in libc++. This
adds the complete tzdb_list class and a minimal tzdb class. The tzdb
class only contains the version, which is used by reload_tzdb.
Next to these classes it contains documentation and build system support
needed for time zone support. The code depends on the IANA Time Zone
Database, which should be available on the platform used or provided by
the libc++ vendors.
The code is labeled as experimental since there will be ABI breaks
during development; the tzdb class needs to have the standard headers.
Implements parts of:
- P0355 Extending <chrono> to Calendars and Time Zones
Addresses:
- LWG3319 Properly reference specification of IANA time zone database
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D154282
This way, we don't need to remove the contents of the ReleaseNotes file
after the branch. This should make it much easier and natural to cherry-pick
changes onto the release branch. Typically, we need two patches for those.
First, we need the code changes against `main`, and then we need a patch
that updates the release notes on the just-created branch.
By versioning the release notes, it becomes easy to author a change
against `main` that targets a just-branched LLVM release by simply
adding it to the release notes for the right version. This has been
a pain point in previous releases.
Differential Revision: https://reviews.llvm.org/D155024
This patch only adds new configuration knobs -- the actual assertions
will be added in follow-up patches.
Differential Revision: https://reviews.llvm.org/D153902
The patch is based on D144994.
D151030 added the module definitions for the module std.
This patch wires in the module and enables the basic testing.
Some notable features are missing:
- There is no test that libc++ can be fully imported as a module.
- This lacks the parts for the std.compat module.
- The module is not shipped with libc++.
Implements parts of
- P2465R3 Standard Library Modules std and std.compat
Reviewed By: ldionne, aaronmondal, #libc
Differential Revision: https://reviews.llvm.org/D151814
Clang has been updated to support C++26, this adds the same support for
libc++. At the moment C++23 and C++26 are identical. During the next
plenary in June the first C++26 papers will be voted on.
Note like Clang this patch uses C++26 is the internal part and C++2c in
the user visible part.
Depends on D150795
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D151026
During the ISO C++ Committee meeting plenary session the C++23 Standard
has been voted as technical complete.
This updates the reference to c++2b to c++23 and updates the __cplusplus
macro.
Note since we use clang-tidy 16 a small work-around is needed. Clang
knows -std=c++23 but clang-tidy not so for now force the lit compiler
flag to use -std=c++2b instead of -std=c++23.
Reviewed By: #libc, philnik, jloser, ldionne
Differential Revision: https://reviews.llvm.org/D150795
Committing on behalf of davidben. Reviewed as D146190
Patch originally by Jan Dörrie in https://reviews.llvm.org/D120064. I've just updated it to include tests, and update documentation that MSVC ABI is not stable.
In the current implementation both `std::optional` and `std::variant` don't perform the EBO on MSVC's ABI. This is because both classes inherit from multiple empty base classes, which breaks the EBO for MSVC. This patch fixes this issue by applying the `empty_bases` declspec attribute, which is already used to fix a similar issue for `std::tuple`.
See https://reviews.llvm.org/D120064 for discussion on MSVC ABI stability. From the discussion, libc++ doesn't have users that expect a stable ABI on MSVC. The fix is thus applied unconditionally to benefit more users. Documentation has been updated to reflect this.
Fixes https://github.com/llvm/llvm-project/issues/61095.
This patch bumps the minimum macOS version for building the dylib
or back-deploying a statically-linked libc++ from macOS 10.11 to
macOS 10.13. AFAICT, Chrome was the last one to require macOS 10.11,
but since then they have bumped their minimal supported version to
macOS 10.13.
Differential Revision: https://reviews.llvm.org/D145012
