Uses an absolute path to the selected binary.
Updates the formatting of two files to match clang-format-16 style.
Depends on D144126
Reviewed By: #libc, philnik
Differential Revision: https://reviews.llvm.org/D144132
Several improvements
- Only add files that we actually want to format.
- Sort according to a fixed locale.
Some drive-by fixes
- Rename a text file, this avoids a filter exception.
- Adds a some missing source files extensions.
- Removes unused extensions hh, hxx, cc, and cxx from clang-format.
Reviewed By: philnik, #libc
Differential Revision: https://reviews.llvm.org/D144126
This change is almost fully mechanical. The only interesting change is in `generate_feature_test_macro_components.py` to generate `_LIBCPP_STD_VER >=` instead. To avoid churn in the git-blame this commit should be added to the `.git-blame-ignore-revs` once committed.
Reviewed By: ldionne, var-const, #libc
Spies: jloser, libcxx-commits, arichardson, arphaman, wenlei
Differential Revision: https://reviews.llvm.org/D143962
It is quite confusing to newcomers that the formatting check gets mostly ignored. To fix that, enforce the formatting for new file and already formatted files, but ignore it for any files that aren't formatted already. We ignore the tests for now, since almost no test is formatted currently, and they are changed almost never.
Reviewed By: ldionne, Mordante, #libc
Spies: arichardson, fedor.sergeev, phosek, sstefan1, libcxx-commits, abrachet
Differential Revision: https://reviews.llvm.org/D142180
Updates the LLVM versions used in the Dockerfile. It also removes
obsolete symlinks. This doesn't update the Buildkite jobs, they need to
use the new Docker image before they can be updated.
Reviewed By: ldionne, #libc, philnik
Differential Revision: https://reviews.llvm.org/D143007
Some clients use libc++ with modules and LSV (Local Submodule Visibility)
enabled, and we see frequent downstream breakage caused by that. Until
modules use LSV by default (which is apparently a desire), add a CI job
that tests this sub-configuration to avoid high cost downstream breakage.
For more information about LSV, see https://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20150504/128395.html.
Differential Revision: https://reviews.llvm.org/D143273
We've been shipping <coroutine> since LLVM 14, so LLVM 17 won't ship
the <experimental/coroutine> header per our policy for removing TSes.
Differential Revision: https://reviews.llvm.org/D108697
This at least allows us to stand up libc++ FreeBSD CI and avoid future
regressions. The failures do need to be addressed, and can be done
iteratively.
Reviewed By: philnik, Mordante
Differential Revision: https://reviews.llvm.org/D141542
`_LIBCPP_REMOVE_TRANSITIVE_INCLUDES` doesn't do anything anymore in C++23 mode, so it's now just a duplicate of the C++23 configuration.
Also add new steps to the post-release checklist for updating the supported compilers.
Reviewed By: ldionne, #libc
Spies: arichardson, libcxx-commits, arphaman
Differential Revision: https://reviews.llvm.org/D133364
All C++20 Ranges papers and LWG issues are done, with the exception of
https://wg21.link/P2210R2 ("Superior String Splitting"), and marked as
such.
All of these were already implemented prior to this patch except bumping
the feature test macro `__cpp_lib_ranges` as required by
https://wg21.link/P2325R3 ("Views should not be required to be default
constructible"). Note that, even though P2325R3 was voted into C++23, it
was voted with a recommendation for vendors to retroactively apply the
change to C++20 (see https://github.com/cplusplus/papers/issues/1007).
Differential Revision: https://reviews.llvm.org/D139900
Most people don't have a versioned clang-tidy locally. This allows them to still run the clang-tidy test if they have a suitable version.
Reviewed By: ldionne, #libc
Spies: libcxx-commits, arichardson
Differential Revision: https://reviews.llvm.org/D141241
Hardcode the version of the tools used in the test feature script
instead of the tests. By changing the hard-coded location it's
easier to make the location flexible in the future.
Drive-by change
- The minimum required version for clang-query is now 15, which matches
our future idea as outlined in the Dockerfile.
- The minimum required version for clang-tidy is now 16, which enables
the new clang-tidy ADL plugin. This plugin is disabled for C++03
due to false positives when using `noexcept`, which is not an operator
in C++03.
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D139545
Rename the `__tuple` directory in libc++ headers to `__tuple_dir`
to avoid file collision when installing. Historically, `__tuple` has
been a file and it has been replaced by a directory
in 2d52c6bfae801b016dd3627b8c0e7c4a99405549. Replacing a regular file
with a directory (or more importantly, the other way around when
downgrading) is not universally supported. Since this is an internal
header, its actual name should not matter, so just rename it to avoid
problems.
Differential Revision: https://reviews.llvm.org/D139270
Implements:
- LWG3792 __cpp_lib_constexpr_algorithms should also be defined in <utility>
Depends on D140407
Reviewed By: #libc, philnik, ldionne
Differential Revision: https://reviews.llvm.org/D140413
This is now everything that is required for clang-tidy checks.
Reviewed By: #libc, ldionne
Spies: libcxx-commits, arichardson
Differential Revision: https://reviews.llvm.org/D140424
ELF Tool Chain provides alternatives to most GNU binutils tools,
including readelf. These tools are currently used by FreeBSD.
ELF Tool Chain's readelf currently emits headings for symbol table
information in a slightly different format compared to GNU or LLVM
readelf. Accept both formats.
Reviewed by: philnik
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.llvm.org/D140313
The clang-tidy checks can't be properly implemented before LLVM16 because the Clang CMake files don't provide the version before.
Reviewed By: Mordante, #libc
Spies: libcxx-commits, arichardson
Differential Revision: https://reviews.llvm.org/D140071
The version used is now determined by Buildkite instead of using the
hard-coded version in the Docker image.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D139341
Buildkite doesn't provide a way to list bot owners so currently
we are pinging people on Discord and Phabricator.
Which works ok until that person is on vacation. This file gives us
a place to list multiple people, or group contacts for each bot.
I've stuck to the CODE_OWNERS.txt format because there's no great
reason to change it.
Reviewed By: #libc, EricWF, ldionne
Differential Revision: https://reviews.llvm.org/D138445
This makes it possible for programmers to run IWYU and get more accurate
standard library inclusions. Prior to this commit, the following program
would be transformed thusly:
```cpp
// Before
#include <algorithm>
#include <vector>
void f() {
auto v = std::vector{0, 1};
std::find(std::ranges::begin(v), std::ranges::end(v), 0);
}
```
```cpp
// After
#include <__algorithm/find.h>
#include <__ranges/access.h>
#include <vector>
...
```
There are two ways to fix this issue: to use [comment pragmas](https://github.com/include-what-you-use/include-what-you-use/blob/master/docs/IWYUPragmas.md)
on every private include, or to write a canonical [mapping file](https://github.com/include-what-you-use/include-what-you-use/blob/master/docs/IWYUMappings.md)
that provides the tool with a manual on how libc++ is laid out. Due to
the complexity of libc++, this commit opts for the latter, to maximise
correctness and minimise developer burden.
To mimimise developer updates to the file, it makes use of wildcards
that match everything within listed subdirectories. A script has also
been added to ensure that the mapping is always fresh in CI, and makes
the process a single step.
Finally, documentation has been added to inform users that IWYU is
supported, and what they need to do in order to leverage the mapping
file.
Closes#56937.
Differential Revision: https://reviews.llvm.org/D138189
This allows porting the library to platforms that are able to support
<iostream> but that do not have a notion of a filesystem, and where it
hence doesn't make sense to support std::fstream (and never will).
Also, remove reliance on <fstream> in various tests that didn't
actually need it.
Differential Revision: https://reviews.llvm.org/D138327
