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
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
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 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
In the second leg of the CI the steps take about:
- C++2b 10m
- C++11 8m
- C++03 6m
- Modular build 10m
- GCC 12 / C++latest 20m
So the slowest job is scheduled last. The CI will wait to start the
third leg until that job is done. The current order increases the
latency of the current job, instead start the slow jobs earlier.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D136276
This is a breaking change. If you were passing one of those three runtimes
in LLVM_ENABLE_PROJECTS, you need to start passing them in LLVM_ENABLE_RUNTIMES
instead. The runtimes in LLVM_ENABLE_RUNTIMES will start being built using
the "bootstrapping build" instead, which means that they will be built
using the just-built Clang. This is usually what you wanted anyway.
If you were using LLVM_ENABLE_PROJECTS=all with the explicit goal of
building these three runtimes, you can now use LLVM_ENABLE_RUNTIMES=all
and these runtimes will be built using the bootstrapping build.
NOTE: This is a re-application of 887b8bd733 which had been reverted
in 6b03a4fea0 because it broke the Sphinx documentation publishers.
The Sphinx documentation publishers have now been moved to using
the runtimes build, so this should not be an issue anymore.
Differential Revision: https://reviews.llvm.org/D132480
Now that all jobs have moved over to the new style of Lit configuration,
we can remove all traces of the legacy testing configuration system.
This includes:
- Cache settings that are not honored or useful anymore
- Several CMake options that were only useful in the context of the
legacy Lit configuration system
- A bunch of Python support code that is not used anymore
- The legacy lit.cfg.in files themselves
Differential Revision: https://reviews.llvm.org/D134650
The new version is a lot simpler and has less option which were not
used. This uses the CSV files as generated by D133127 as input data.
The current Python script has more features but uses a simple "grep"
making the output less accurate:
- Conditionally included header are always included. This is an issue
since part of our includes are unneeded transitive includes. Based on
the language version they may be omitted. The script however always
includes them.
- Includes in comments are processed as-if they are includes. This is an
issue when comments explain how certain data is generated; of course
there are digraphs which the script omits.
This implementation uses Clang's --trace-includes to generate the includes
per header. This means the input of the generation script always has the
real list of includes.
Libc++ is moving from large monolithic Standard headers to more fine
grained headers. For example, algorithm includes every header in
`__algorithm`. Adding all these detail headers in the graph makes the
output unusable. Instead it only shows the Standard headers. The
transitive includes of the detail headers are parsed and "attributed" to
the Standard header including them. This gives an accurate include graph
without the unneeded clutter. Note that this graph is still big.
This changes fixes the cyclic dependency issue with the previous version
of the tool so the markers and its documentation is removed.
Since the input has no cycles the CI test is removed.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D134188
This is a breaking change. If you were passing one of those three runtimes
in LLVM_ENABLE_PROJECTS, you need to start passing them in LLVM_ENABLE_RUNTIMES
instead. The runtimes in LLVM_ENABLE_RUNTIMES will start being built using
the "bootstrapping build" instead, which means that they will be built
using the just-built Clang. This is usually what you wanted anyway.
If you were using LLVM_ENABLE_PROJECTS=all with the explicit goal of
building these three runtimes, you can now use LLVM_ENABLE_RUNTIMES=all
and these runtimes will be built using the bootstrapping build.
Differential Revision: https://reviews.llvm.org/D132480
The libc++ pre-commit CI uses Clang nightly builds. Currently it's not
possible to determine the exact version used since CMake doesn't show
this information by default. Instead use the --version flag to get this
information.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D133122
After upgrading the type deduction machinery to retain type sugar in
D110216, we were left with a situation where there is no general
well behaved mechanism in Clang to unify the type sugar of multiple
deductions of the same type parameter.
So we ended up making an arbitrary choice: keep the sugar of the first
deduction, ignore subsequent ones.
In general, we already had this problem, but in a smaller scale.
The result of the conditional operator and many other binary ops
could benefit from such a mechanism.
This patch implements such a type sugar unification mechanism.
The basics:
This patch introduces a `getCommonSugaredType(QualType X, QualType Y)`
method to ASTContext which implements this functionality, and uses it
for unifying the results of type deduction and return type deduction.
This will return the most derived type sugar which occurs in both X and
Y.
Example:
Suppose we have these types:
```
using Animal = int;
using Cat = Animal;
using Dog = Animal;
using Tom = Cat;
using Spike = Dog;
using Tyke = Dog;
```
For `X = Tom, Y = Spike`, this will result in `Animal`.
For `X = Spike, Y = Tyke`, this will result in `Dog`.
How it works:
We take two types, X and Y, which we wish to unify as input.
These types must have the same (qualified or unqualified) canonical
type.
We dive down fast through top-level type sugar nodes, to the
underlying canonical node. If these canonical nodes differ, we
build a common one out of the two, unifying any sugar they had.
Note that this might involve a recursive call to unify any children
of those. We then return that canonical node, handling any qualifiers.
If they don't differ, we walk up the list of sugar type nodes we dived
through, finding the last identical pair, and returning that as the
result, again handling qualifiers.
Note that this patch will not unify sugar nodes if they are not
identical already. We will simply strip off top-level sugar nodes that
differ between X and Y. This sugar node unification will instead be
implemented in a subsequent patch.
This patch also implements a few users of this mechanism:
* Template argument deduction.
* Auto deduction, for functions returning auto / decltype(auto), with
special handling for initializer_list as well.
Further users will be implemented in a subsequent patch.
Signed-off-by: Matheus Izvekov <mizvekov@gmail.com>
Differential Revision: https://reviews.llvm.org/D111283
This implements setting the equivalent of `-fcrash-diagnostics-dir`
through the environment variable `CLANG_CRASH_DIAGNOSTICS_DIR`.
If present, the flag still takes precedence.
This helps integration with test frameworks and pipelines.
With this feature, we change the libcxx bootstrapping build
pipeline to produce clang crash reproducers as artifacts.
Signed-off-by: Matheus Izvekov <mizvekov@gmail.com>
Differential Revision: https://reviews.llvm.org/D133082
Changes the CI to use the Clang 16 nightly builds instead of Clang 14.
(The libc++15 branch was accidentally build using Clang 14 instead of
Clang 15; hence the skipping of a number.)
Also adds a Clang 15 build to the test matrix.
Based on the private discussion with @ldionne we decided to move
the configuration parameters from the `run-buildbot` script to the
CI configuration `buildkite-pipeline.yml`. Other hard-coded values
from the Dockerfile should be move to the CI configuration too. That
will be done in another commit.
C++17 will use Clang-15 since D131479 causes a test to fail.
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D131174
This commit reverts the following commits:
- 952f90b72b
- e6a0800532 (D132298)
- 176db3b3ab (D132324)
These commits caused CI instability and need to be reverted in order
to figure things out again. See the discussion in https://llvm.org/D132324
for more information.
This has been officially deprecated since D112724, meaning the
deprecation warning is present in released 14 and 15.
This makes me think that now, shortly after the 15 release is branched,
is a good time to pull the trigger.
Reviewed By: phosek
Differential Revision: https://reviews.llvm.org/D132324
_HAS_EXCEPTIONS=0 allows disabling the exception parts of the MS STL
and vcruntime, and e.g. compiler-rt/lib/fuzzer sets this define (to
work around issues with MS STL). If using libc++ instead of MS STL,
this define previously broke the libc++ headers.
If _HAS_EXCEPTIONS is set to 0, the vcruntime_exception.h header
doesn't define the ABI base class std::exception. If no exceptions
are going to be thrown, this probably is fine (although it also
breaks using subclasses of it as regular objects that aren't thrown),
but it requires ifdeffing out all subclasses of all exception/error
derived objects (which are sprinkled throughout the headers).
Instead, libc++ will supply an ABI compatible definition when
_HAS_EXCEPTIONS is set to 0, which will make the class hierarchies
complete.
In this build configuration, one can still create instances of
exception subclasses, and those objects will be ABI incompatible
with the ones from when _HAS_EXCEPTIONS isn't defined to 0 - but
one may argue that's a pathological/self-imposed problem in that case.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D103947
Since we branched LLVM install Clang 16 and remove Clang 12.
Currently our Docker installs 4 versions of Clang so our CI can use the
same image for both the main and the release branch. This wasn't done for
the other Clang tools so they always use the same version for testing
the main and the release branch. Instead install 2 versions for the
tools.
However it seems the default for Clang and its tools were the latest
released version instead of the ToT. To lessen the risk of breaking the
release CI, version 14 is installed hard-coded as a temporary solution.
Updating the main branch to use the Clang 16 compiler will be done in a
separate patch.
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D131324
When back-deploying to older platforms, we can still provide assertions,
but we might not be able to provide a great implementation for the verbose
handler. Instead, we can just call ::abort().
Differential Revision: https://reviews.llvm.org/D131199
This is required for using clang-query in the CI
Reviewed By: Mordante, #libc
Spies: libcxx-commits, arichardson
Differential Revision: https://reviews.llvm.org/D130845
Leave the escape hatch in place with a note, but don't include the
debug mode symbols by default since we don't support the debug mode
in the normal library anymore.
This is technically an ABI break for users who were depending on
those debug mode symbols in the dylib, however those users will
already be broken at compile-time because they must have been using
_LIBCPP_DEBUG=2, which is now an error.
Differential Revision: https://reviews.llvm.org/D127360
In particular remove the ability to expel incomplete features from the
library at configure-time, since this can now be done through the
_LIBCPP_ENABLE_EXPERIMENTAL macro.
Also, never provide symbols related to incomplete features inside the
dylib, instead provide them in c++experimental.a (this changes the
symbols list, but not for any configuration that should have shipped).
Differential Revision: https://reviews.llvm.org/D128928
