mirrors/llvm-project
0
0
Fork 0
mirror of https://github.com/llvm/llvm-project.git synced 2025-04-29 02:16:06 +00:00
Code Issues Projects Releases Wiki Activity
llvm-project/libcxx/utils/ci/run-buildbot

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

614 lines
22 KiB
Plaintext
Raw Normal View History

[libc++] Initial support for pre-commit CI with Buildkite This commit adds basic files and scripts that are used for the Buildkite pre-commit CI setup. This was tested to mostly work on a fork of llvm-project, however some adjustments will have to be made as we complete the real setup.
2020-09-23 09:20:03 -04:00
#!/usr/bin/env bash
#===----------------------------------------------------------------------===##
#
# Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
# See https://llvm.org/LICENSE.txt for license information.
# SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
#
#===----------------------------------------------------------------------===##
set -ex
[libc++] Add format check to CI Note: contrary to what I said previously, I didn't change .clang-format nor utils/generate_feature_test_macro_components.py script. Reviewed By: ldionne, #libc Differential Revision: https://reviews.llvm.org/D92229
2021-02-04 21:13:22 +01:00
set -o pipefail
[libc++] [test] Recommit the unsetting of LC_COLLATE in the builder script. This re-reverts one piece of 1b885573327d0f6b36f24ad23d243642f658750b, reapplying one piece of D101437 (but not the "service"-queue piece of it). It turns out that the behavior of `grep [^ -~]`, or even `grep [A-Z]`, depends on locale, specifically `LC_COLLATE`. So we want to make sure we're not in any weird locale, no matter what machine we're running on. Yes, "en_US.UTF-8" counts as weird! https://stackoverflow.com/questions/67320156/misbehavior-of-gnu-grep-when-grepping-for-ignores-spaces https://stackoverflow.com/questions/6799872/how-to-make-grep-a-z-independent-of-locale
2021-04-30 14:43:33 -04:00
unset LANG
unset LC_ALL
unset LC_COLLATE
[libc++] Initial support for pre-commit CI with Buildkite This commit adds basic files and scripts that are used for the Buildkite pre-commit CI setup. This was tested to mostly work on a fork of llvm-project, however some adjustments will have to be made as we complete the real setup.
2020-09-23 09:20:03 -04:00
[libc++] Allow customizing a few paths when running build bots This allows reusing run-buildbot for downstream testing as well.
2020-11-05 19:02:32 -05:00
PROGNAME="$(basename "${0}")"
function usage() {
cat <<EOF
Usage:
${PROGNAME} [options] <BUILDER>
[-h|--help] Display this help and exit.
--llvm-root <DIR> Path to the root of the LLVM monorepo. By default, we try
to figure it out based on the current working directory.
[libc++] Also allow customizing the build directory when running CI
2020-11-05 19:09:03 -05:00
--build-dir <DIR> The directory to use for building the library. By default,
this is '<llvm-root>/build/<builder>'.
[libc++] Allow customizing a few paths when running build bots This allows reusing run-buildbot for downstream testing as well.
2020-11-05 19:02:32 -05:00
--osx-roots <DIR> Path to pre-downloaded macOS dylibs. By default, we download
them from Green Dragon. This is only relevant at all when
running back-deployment testing if one wants to override
the old dylibs we use to run the tests with different ones.
EOF
}
while [[ $# -gt 0 ]]; do
case ${1} in
-h|--help)
usage
exit 0
;;
--llvm-root)
MONOREPO_ROOT="${2}"
shift; shift
;;
[libc++] Also allow customizing the build directory when running CI
2020-11-05 19:09:03 -05:00
--build-dir)
BUILD_DIR="${2}"
shift; shift
;;
[libc++] Allow customizing a few paths when running build bots This allows reusing run-buildbot for downstream testing as well.
2020-11-05 19:02:32 -05:00
--osx-roots)
OSX_ROOTS="${2}"
shift; shift
;;
*)
BUILDER="${1}"
shift
;;
esac
done
MONOREPO_ROOT="${MONOREPO_ROOT:="$(git rev-parse --show-toplevel)"}"
[libc++] Also allow customizing the build directory when running CI
2020-11-05 19:09:03 -05:00
BUILD_DIR="${BUILD_DIR:=${MONOREPO_ROOT}/build/${BUILDER}}"
[libc++] Fix typo in run-buildbot The installation directory was never meant to contain a brace.
2021-01-07 17:37:09 -05:00
INSTALL_DIR="${BUILD_DIR}/install"
[libc++] Initial support for pre-commit CI with Buildkite This commit adds basic files and scripts that are used for the Buildkite pre-commit CI setup. This was tested to mostly work on a fork of llvm-project, however some adjustments will have to be made as we complete the real setup.
2020-09-23 09:20:03 -04:00
[libc++] Use Xcode's CMake if it's present This resolves issues when the CMake in use on the host is too old to configure libc++ properly, but Xcode has a sufficiently recent version. It is technically possible for the reverse issue to happen, where the Xcode version would be too old and the user-installed version would be better, however in the context of our build bots, we use AppleClang on Apple platforms, and the CMake shipped with Xcode should work with the AppleClang shipped alongside that Xcode. Differential Revision: https://reviews.llvm.org/D102083
2021-05-07 13:14:57 -04:00
# If we can find Ninja/CMake provided by Xcode, use those since we know their
# version will generally work with the Clang shipped in Xcode (e.g. if Clang
# knows about -std=c++20, the CMake bundled in Xcode will probably know about
# that flag too).
if xcrun --find ninja &>/dev/null; then NINJA="$(xcrun --find ninja)"; else NINJA="ninja"; fi
if xcrun --find cmake &>/dev/null; then CMAKE="$(xcrun --find cmake)"; else CMAKE="cmake"; fi
[libc++] Properly pick up the Ninja from Xcode in the CI script
2021-03-04 16:01:36 -05:00
[libc++] Allow customizing a few paths when running build bots This allows reusing run-buildbot for downstream testing as well.
2020-11-05 19:02:32 -05:00
function clean() {
rm -rf "${BUILD_DIR}"
}
[libcxx] [ci] Add a Windows CI configuration for a statically linked libc++ On Windows, static vs DLL linking affects details in quite a few cases, so it's good to have coverage for both cases. Testing with static linking also increases coverage for a number of cases and individual checks that have had to be waived for the DLL case, and allows testing libc++experimental, increasing the number of test cases actually executed by 180 (176 new tests from libc++experimental and 4 ones that are XFAIL windows-dll). Also drop the "generic-" prefix from these configuration names, as they're perhaps not what the "generic" prefix intended originally in the other generic-posix configurations. Differential Revision: https://reviews.llvm.org/D101565
2021-04-06 00:17:30 +03:00
function generate-cmake-base() {
[libc++] Refactor the run-buildbot script to make it more modular, and run the benchmarks As a fly-by fix, unbreak the benchmarks on Apple platforms. Differential Revision: https://reviews.llvm.org/D90043
2020-10-23 10:02:14 -04:00
echo "--- Generating CMake"
[libc++] Use Xcode's CMake if it's present This resolves issues when the CMake in use on the host is too old to configure libc++ properly, but Xcode has a sufficiently recent version. It is technically possible for the reverse issue to happen, where the Xcode version would be too old and the user-installed version would be better, however in the context of our build bots, we use AppleClang on Apple platforms, and the CMake shipped with Xcode should work with the AppleClang shipped alongside that Xcode. Differential Revision: https://reviews.llvm.org/D102083
2021-05-07 13:14:57 -04:00
${CMAKE} \
[runtimes] Use the new "runtimes" build by default and deprecate other builds This commit makes the new "runtimes" build (with <monorepo>/runtimes as the root of the CMake invocation) the default way of building libc++. The other supported way of building libc++ is the "bootstrapping" build, where `<monorepo>/llvm` is used as the root of the CMake invocation. All other ways of building libc++ are deprecated effective immediately. There should be no use-case for building libc++ that isn't supported by one of these two builds, and the two new builds work on all environments and are lightweight. They will also make it possible to greatly simplify the build infrastructure of the runtimes, which is currently way too convoluted. Differential Revision: https://reviews.llvm.org/D111356
2021-10-07 16:19:11 -04:00
-S "${MONOREPO_ROOT}/runtimes" \
[libc++] Refactor the run-buildbot script to make it more modular, and run the benchmarks As a fly-by fix, unbreak the benchmarks on Apple platforms. Differential Revision: https://reviews.llvm.org/D90043
2020-10-23 10:02:14 -04:00
-B "${BUILD_DIR}" \
[libc++] Properly pick up the Ninja from Xcode in the CI script
2021-03-04 16:01:36 -05:00
-GNinja -DCMAKE_MAKE_PROGRAM="${NINJA}" \
[libc++] Refactor the run-buildbot script to make it more modular, and run the benchmarks As a fly-by fix, unbreak the benchmarks on Apple platforms. Differential Revision: https://reviews.llvm.org/D90043
2020-10-23 10:02:14 -04:00
-DCMAKE_BUILD_TYPE=RelWithDebInfo \
-DCMAKE_INSTALL_PREFIX="${INSTALL_DIR}" \
[libcxx] [ci] Enable LIBCXX_ENABLE_WERROR where possible Only opt out from it in the few configs (GCC based) where there still are build warnings. Differential Revision: https://reviews.llvm.org/D119573
2022-02-10 13:08:24 +02:00
-DLIBCXX_ENABLE_WERROR=YES \
[libcxx] [ci] Enable -Werror for libcxxabi and libunwind too Differential Revision: https://reviews.llvm.org/D122800
2022-03-31 11:51:30 +03:00
-DLIBCXXABI_ENABLE_WERROR=YES \
-DLIBUNWIND_ENABLE_WERROR=YES \
[libc++] Forgot to bump the CI timeout everywhere
2022-06-07 10:01:01 -04:00
-DLLVM_LIT_ARGS="-sv --show-unsupported --xunit-xml-output test-results.xml --timeout=1500 --time-tests" \
[libcxx] [ci] Add a Windows CI configuration for a statically linked libc++ On Windows, static vs DLL linking affects details in quite a few cases, so it's good to have coverage for both cases. Testing with static linking also increases coverage for a number of cases and individual checks that have had to be waived for the DLL case, and allows testing libc++experimental, increasing the number of test cases actually executed by 180 (176 new tests from libc++experimental and 4 ones that are XFAIL windows-dll). Also drop the "generic-" prefix from these configuration names, as they're perhaps not what the "generic" prefix intended originally in the other generic-posix configurations. Differential Revision: https://reviews.llvm.org/D101565
2021-04-06 00:17:30 +03:00
"${@}"
}
function generate-cmake() {
generate-cmake-base \
[runtimes] Use the new "runtimes" build by default and deprecate other builds This commit makes the new "runtimes" build (with <monorepo>/runtimes as the root of the CMake invocation) the default way of building libc++. The other supported way of building libc++ is the "bootstrapping" build, where `<monorepo>/llvm` is used as the root of the CMake invocation. All other ways of building libc++ are deprecated effective immediately. There should be no use-case for building libc++ that isn't supported by one of these two builds, and the two new builds work on all environments and are lightweight. They will also make it possible to greatly simplify the build infrastructure of the runtimes, which is currently way too convoluted. Differential Revision: https://reviews.llvm.org/D111356
2021-10-07 16:19:11 -04:00
-DLLVM_ENABLE_RUNTIMES="libcxx;libcxxabi;libunwind" \
[libc++] Refactor the run-buildbot script to make it more modular, and run the benchmarks As a fly-by fix, unbreak the benchmarks on Apple platforms. Differential Revision: https://reviews.llvm.org/D90043
2020-10-23 10:02:14 -04:00
-DLIBCXX_CXX_ABI=libcxxabi \
[libc++] Add a Buildkite job that tests back-deployment on Apple The current way we test this is pretty cheap, i.e. we download previously released macOS dylibs and run against that. Ideally, we would require a full host running the appropriate version of macOS, and we'd execute the tests using SSH on that host. But since we don't have such hosts available easily for now, this is better than nothing. At the same time, also fix some tests that were failing when back deploying. Differential Revision: https://reviews.llvm.org/D90869
2020-11-05 10:47:06 -05:00
"${@}"
}
[libcxx] [ci] Add a Windows CI configuration for a statically linked libc++ On Windows, static vs DLL linking affects details in quite a few cases, so it's good to have coverage for both cases. Testing with static linking also increases coverage for a number of cases and individual checks that have had to be waived for the DLL case, and allows testing libc++experimental, increasing the number of test cases actually executed by 180 (176 new tests from libc++experimental and 4 ones that are XFAIL windows-dll). Also drop the "generic-" prefix from these configuration names, as they're perhaps not what the "generic" prefix intended originally in the other generic-posix configurations. Differential Revision: https://reviews.llvm.org/D101565
2021-04-06 00:17:30 +03:00
function generate-cmake-libcxx-win() {
# TODO: Clang-cl in MSVC configurations don't have access to compiler_rt
# builtins helpers for int128 division. See
# https://reviews.llvm.org/D91139#2429595 for a comment about longterm
# intent for handling the issue. In the meantime, define
# -D_LIBCPP_HAS_NO_INT128 (both when building the library itself and
# when building tests) to allow enabling filesystem for running tests,
# even if it uses a non-permanent ABI.
generate-cmake-base \
[runtimes] Use the new "runtimes" build by default and deprecate other builds This commit makes the new "runtimes" build (with <monorepo>/runtimes as the root of the CMake invocation) the default way of building libc++. The other supported way of building libc++ is the "bootstrapping" build, where `<monorepo>/llvm` is used as the root of the CMake invocation. All other ways of building libc++ are deprecated effective immediately. There should be no use-case for building libc++ that isn't supported by one of these two builds, and the two new builds work on all environments and are lightweight. They will also make it possible to greatly simplify the build infrastructure of the runtimes, which is currently way too convoluted. Differential Revision: https://reviews.llvm.org/D111356
2021-10-07 16:19:11 -04:00
-DLLVM_ENABLE_RUNTIMES="libcxx" \
[libcxx] [ci] Add a Windows CI configuration for a statically linked libc++ On Windows, static vs DLL linking affects details in quite a few cases, so it's good to have coverage for both cases. Testing with static linking also increases coverage for a number of cases and individual checks that have had to be waived for the DLL case, and allows testing libc++experimental, increasing the number of test cases actually executed by 180 (176 new tests from libc++experimental and 4 ones that are XFAIL windows-dll). Also drop the "generic-" prefix from these configuration names, as they're perhaps not what the "generic" prefix intended originally in the other generic-posix configurations. Differential Revision: https://reviews.llvm.org/D101565
2021-04-06 00:17:30 +03:00
-DCMAKE_C_COMPILER=clang-cl \
-DCMAKE_CXX_COMPILER=clang-cl \
-DLIBCXX_ENABLE_FILESYSTEM=YES \
[libcxx] Add LIBCXX_EXTRA_SITE_DEFINES for adding extra defines in __config_site This is similar to the existing setting LIBCXX_ABI_DEFINES, with the difference that this also allows setting other defines than ones that start with "_LIBCPP_ABI_", and allows setting defines to a specific value. This allows avoiding using LIBCXX_TEST_COMPILER_FLAGS in two CI configurations. Differential Revision: https://reviews.llvm.org/D116109
2021-12-21 01:19:34 +02:00
-DLIBCXX_EXTRA_SITE_DEFINES="_LIBCPP_HAS_NO_INT128" \
[libcxx] [ci] Add a Windows CI configuration for a statically linked libc++ On Windows, static vs DLL linking affects details in quite a few cases, so it's good to have coverage for both cases. Testing with static linking also increases coverage for a number of cases and individual checks that have had to be waived for the DLL case, and allows testing libc++experimental, increasing the number of test cases actually executed by 180 (176 new tests from libc++experimental and 4 ones that are XFAIL windows-dll). Also drop the "generic-" prefix from these configuration names, as they're perhaps not what the "generic" prefix intended originally in the other generic-posix configurations. Differential Revision: https://reviews.llvm.org/D101565
2021-04-06 00:17:30 +03:00
"${@}"
}
[runtimes][ci] Run the tests for libunwind in the CI We should arguably have always been doing that. The state of libunwind is quite sad, so this commit adds several XFAILs to make the CI pass. We need to investigate why so many tests are not passing in some configurations, but I'll defer that to folks who actually work on libunwind for lack of bandwidth. Differential Revision: https://reviews.llvm.org/D110872
2021-09-30 15:11:48 -04:00
function check-runtimes() {
echo "--- Installing libc++, libc++abi and libunwind to a fake location"
${NINJA} -vC "${BUILD_DIR}" install-cxx install-cxxabi install-unwind
[libc++] Add a CI configuration with static libc++/libc++abi Differential Revision: https://reviews.llvm.org/D99268
2021-03-24 09:50:59 -04:00
[libc++] Refactor the run-buildbot script to make it more modular, and run the benchmarks As a fly-by fix, unbreak the benchmarks on Apple platforms. Differential Revision: https://reviews.llvm.org/D90043
2020-10-23 10:02:14 -04:00
echo "+++ Running the libc++ tests"
[libc++] Run ninja with --verbose This makes it easier to see what exact build commands are used. Differential Revision: https://reviews.llvm.org/D98992
2021-03-19 16:26:15 -07:00
${NINJA} -vC "${BUILD_DIR}" check-cxx
[libc++] Refactor the run-buildbot script to make it more modular, and run the benchmarks As a fly-by fix, unbreak the benchmarks on Apple platforms. Differential Revision: https://reviews.llvm.org/D90043
2020-10-23 10:02:14 -04:00
echo "+++ Running the libc++abi tests"
[libc++] Run ninja with --verbose This makes it easier to see what exact build commands are used. Differential Revision: https://reviews.llvm.org/D98992
2021-03-19 16:26:15 -07:00
${NINJA} -vC "${BUILD_DIR}" check-cxxabi
[runtimes][ci] Run the tests for libunwind in the CI We should arguably have always been doing that. The state of libunwind is quite sad, so this commit adds several XFAILs to make the CI pass. We need to investigate why so many tests are not passing in some configurations, but I'll defer that to folks who actually work on libunwind for lack of bandwidth. Differential Revision: https://reviews.llvm.org/D110872
2021-09-30 15:11:48 -04:00
echo "+++ Running the libunwind tests"
${NINJA} -vC "${BUILD_DIR}" check-unwind
[libc++] Refactor the run-buildbot script to make it more modular, and run the benchmarks As a fly-by fix, unbreak the benchmarks on Apple platforms. Differential Revision: https://reviews.llvm.org/D90043
2020-10-23 10:02:14 -04:00
}
[libc++] Formalize what configurations are covered by the ABI lists By encoding ABI-affecting properties in the name of the ABI list, it makes it clear when an ABI list test should or should not be available, and what results we should expect. Note that we clearly don't encode all ABI-affecting parameters in the name right now -- I just ported over what we supported in the code that was there previously. As we encounter configurations that we wish to support but produce different ABI lists, we can add those to the ABI identifier and start supporting them. This commit also starts checking the ABI list in the CI jobs that run a supported configuration. Eventually, all configurations should have a generated ABI list and the test should even run implicitly as part of the Lit test suite. Differential Revision: https://reviews.llvm.org/D92194
2020-11-26 15:00:42 -05:00
# TODO: The goal is to test this against all configurations. We should also move
# this to the Lit test suite instead of being a separate CMake target.
function check-abi-list() {
echo "+++ Running the libc++ ABI list test"
[libc++] Run ninja with --verbose This makes it easier to see what exact build commands are used. Differential Revision: https://reviews.llvm.org/D98992
2021-03-19 16:26:15 -07:00
${NINJA} -vC "${BUILD_DIR}" check-cxx-abilist || (
[libc++] [P0482] [C++20] Implement missing bits for codecvt and codecvt_byname. Add codecvt*<char16_t, char8_t> and codecvt*<char32_t, char8_t>. Deprecate codecvt<char(16|32)_t, char>. Enable disabled tests. Update _LIBCPP_STD_VER to use 20 for C++20. Add _LIBCPP_DEPRECATED_IN_CXX20 macro. Reviewed By: ldionne, #libc, #libc_abi Differential Revision: https://reviews.llvm.org/D91517
2020-12-02 08:57:02 +01:00
echo "+++ Generating the libc++ ABI list after failed check"
[libc++] Run ninja with --verbose This makes it easier to see what exact build commands are used. Differential Revision: https://reviews.llvm.org/D98992
2021-03-19 16:26:15 -07:00
${NINJA} -vC "${BUILD_DIR}" generate-cxx-abilist
[libc++] [P0482] [C++20] Implement missing bits for codecvt and codecvt_byname. Add codecvt*<char16_t, char8_t> and codecvt*<char32_t, char8_t>. Deprecate codecvt<char(16|32)_t, char>. Enable disabled tests. Update _LIBCPP_STD_VER to use 20 for C++20. Add _LIBCPP_DEPRECATED_IN_CXX20 macro. Reviewed By: ldionne, #libc, #libc_abi Differential Revision: https://reviews.llvm.org/D91517
2020-12-02 08:57:02 +01:00
false
)
[libc++] Formalize what configurations are covered by the ABI lists By encoding ABI-affecting properties in the name of the ABI list, it makes it clear when an ABI list test should or should not be available, and what results we should expect. Note that we clearly don't encode all ABI-affecting parameters in the name right now -- I just ported over what we supported in the code that was there previously. As we encounter configurations that we wish to support but produce different ABI lists, we can add those to the ABI identifier and start supporting them. This commit also starts checking the ABI list in the CI jobs that run a supported configuration. Eventually, all configurations should have a generated ABI list and the test should even run implicitly as part of the Lit test suite. Differential Revision: https://reviews.llvm.org/D92194
2020-11-26 15:00:42 -05:00
}
[libc++] Refactor the run-buildbot script to make it more modular, and run the benchmarks As a fly-by fix, unbreak the benchmarks on Apple platforms. Differential Revision: https://reviews.llvm.org/D90043
2020-10-23 10:02:14 -04:00
function check-cxx-benchmarks() {
echo "--- Running the benchmarks"
[libc++] Run ninja with --verbose This makes it easier to see what exact build commands are used. Differential Revision: https://reviews.llvm.org/D98992
2021-03-19 16:26:15 -07:00
${NINJA} -vC "${BUILD_DIR}" check-cxx-benchmarks
[libc++] Refactor the run-buildbot script to make it more modular, and run the benchmarks As a fly-by fix, unbreak the benchmarks on Apple platforms. Differential Revision: https://reviews.llvm.org/D90043
2020-10-23 10:02:14 -04:00
}
[libc++] Initial support for pre-commit CI with Buildkite This commit adds basic files and scripts that are used for the Buildkite pre-commit CI setup. This was tested to mostly work on a fork of llvm-project, however some adjustments will have to be made as we complete the real setup.
2020-09-23 09:20:03 -04:00
[libc++] Print the CMake version before generating CMake
2021-04-01 13:40:04 -04:00
# Print the version of a few tools to aid diagnostics in some cases
[libc++] Use Xcode's CMake if it's present This resolves issues when the CMake in use on the host is too old to configure libc++ properly, but Xcode has a sufficiently recent version. It is technically possible for the reverse issue to happen, where the Xcode version would be too old and the user-installed version would be better, however in the context of our build bots, we use AppleClang on Apple platforms, and the CMake shipped with Xcode should work with the AppleClang shipped alongside that Xcode. Differential Revision: https://reviews.llvm.org/D102083
2021-05-07 13:14:57 -04:00
${CMAKE} --version
[libc++] Print the CMake version before generating CMake
2021-04-01 13:40:04 -04:00
${NINJA} --version
[libc++] Shows the detailed compiler version info. 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
2022-09-01 18:38:03 +02:00
if [ ! -z "${CXX}" ]; then ${CXX} --version; fi
[libc++] Initial support for pre-commit CI with Buildkite This commit adds basic files and scripts that are used for the Buildkite pre-commit CI setup. This was tested to mostly work on a fork of llvm-project, however some adjustments will have to be made as we complete the real setup.
2020-09-23 09:20:03 -04:00
case "${BUILDER}" in
[libc++] Add format check to CI Note: contrary to what I said previously, I didn't change .clang-format nor utils/generate_feature_test_macro_components.py script. Reviewed By: ldionne, #libc Differential Revision: https://reviews.llvm.org/D92229
2021-02-04 21:13:22 +01:00
check-format)
clean
echo "+++ Checking formatting"
# We need to set --extensions so that clang-format checks extensionless files.
mkdir -p ${BUILD_DIR}
git-clang-format \
--binary /usr/bin/clang-format --diff \
--extensions ',h,hh,hpp,hxx,c,cc,cxx,cpp' HEAD~1 \
-- \
libcxx/{benchmarks,include,src,test} \
libcxxabi/{fuzz,include,src,test} \
| tee ${BUILD_DIR}/clang-format.patch
# Check if the diff is empty, fail otherwise.
! grep -q '^--- a' ${BUILD_DIR}/clang-format.patch
;;
[libc++] [CI] Validate the output of the generated scripts. This adds a CI job validating that the output of utils/generate_feature_test_macro_components.py, libcxx/utils/generate_header_inclusion_tests.py, and utils/generate_header_tests.py are up to date. The validation method has been copied from the Format job. Differential Revision: https://reviews.llvm.org/D99862
2021-04-04 20:11:48 +02:00
check-generated-output)
[libc++][CI] Fix check-generated-output. Before the script detected non-ASCII characters but let them pass. This fixes the issue. I had a way to solve the issue, during review @Quuxplusone suggested a better alternative. The patch has been changed to use this alternative. Intended failed builds: - Not updated generated files https://buildkite.com/llvm-project/libcxx-ci/builds/2822 - Not updated generated files and non-ASCII usage https://buildkite.com/llvm-project/libcxx-ci/builds/2835 - Non-ASCII usage https://buildkite.com/llvm-project/libcxx-ci/builds/2836 Reviewed By: #libc, Quuxplusone, curdeius Differential Revision: https://reviews.llvm.org/D101303
2021-04-28 19:13:52 +02:00
# `! foo` doesn't work properly with `set -e`, use `! foo || false` instead.
# https://stackoverflow.com/questions/57681955/set-e-does-not-respect-logical-not
[libc++] [CI] Validate the output of the generated scripts. This adds a CI job validating that the output of utils/generate_feature_test_macro_components.py, libcxx/utils/generate_header_inclusion_tests.py, and utils/generate_header_tests.py are up to date. The validation method has been copied from the Format job. Differential Revision: https://reviews.llvm.org/D99862
2021-04-04 20:11:48 +02:00
clean
[libc++] Add a CMake target to re-generate files and revamp CONTRIBUTING.rst As we automate more and more things in the library, it becomes useful for contributors to have a single target for running all the automation as part of their workflow. This commit adds a new `libcxx-generate-files` target that should re-generate all the auto-generated files in the library. As a fly-by, I also revamped the documentation on Contributing to account for this new target and present it as a bullet list of things to check before committing. I also added a few things that are often overlooked to that list, such as updating the synopsis and the status files. Differential Revision: https://reviews.llvm.org/D106067
2021-07-15 10:19:39 -04:00
generate-cmake
# Reject patches that forgot to re-run the generator scripts.
echo "+++ Making sure the generator scripts were run"
${NINJA} -vC "${BUILD_DIR}" libcxx-generate-files
[libc++] [CI] Validate the output of the generated scripts. This adds a CI job validating that the output of utils/generate_feature_test_macro_components.py, libcxx/utils/generate_header_inclusion_tests.py, and utils/generate_header_tests.py are up to date. The validation method has been copied from the Format job. Differential Revision: https://reviews.llvm.org/D99862
2021-04-04 20:11:48 +02:00
git diff | tee ${BUILD_DIR}/generated_output.patch
[libc++][ci] Detect not committed generated files. The Generated output CI job only tests for modified files. This job should also fail the generated output contains new files. It would be possible to test modified and untracked files in one execution of `git ls-files`. However the diff is stored as an artifact so the execution of `git diff` would still be required. Discussion: Would it be better to do `git ls-files -om` and remove the excution of `! grep -q '^--- a' ${BUILD_DIR}/generated_output.patch || false` ? (Obviously then the name `generated_output.untracked` should change to something like `generated_output.status`) Reviewed By: #libc, ldionne Differential Revision: https://reviews.llvm.org/D106534
2021-07-22 11:17:53 +02:00
git ls-files -o --exclude-standard | tee ${BUILD_DIR}/generated_output.status
[libc++][CI] Fix check-generated-output. Before the script detected non-ASCII characters but let them pass. This fixes the issue. I had a way to solve the issue, during review @Quuxplusone suggested a better alternative. The patch has been changed to use this alternative. Intended failed builds: - Not updated generated files https://buildkite.com/llvm-project/libcxx-ci/builds/2822 - Not updated generated files and non-ASCII usage https://buildkite.com/llvm-project/libcxx-ci/builds/2835 - Non-ASCII usage https://buildkite.com/llvm-project/libcxx-ci/builds/2836 Reviewed By: #libc, Quuxplusone, curdeius Differential Revision: https://reviews.llvm.org/D101303
2021-04-28 19:13:52 +02:00
! grep -q '^--- a' ${BUILD_DIR}/generated_output.patch || false
[libc++][ci] Detect not committed generated files. The Generated output CI job only tests for modified files. This job should also fail the generated output contains new files. It would be possible to test modified and untracked files in one execution of `git ls-files`. However the diff is stored as an artifact so the execution of `git diff` would still be required. Discussion: Would it be better to do `git ls-files -om` and remove the excution of `! grep -q '^--- a' ${BUILD_DIR}/generated_output.patch || false` ? (Obviously then the name `generated_output.untracked` should change to something like `generated_output.status`) Reviewed By: #libc, ldionne Differential Revision: https://reviews.llvm.org/D106534
2021-07-22 11:17:53 +02:00
if [ -s ${BUILD_DIR}/generated_output.status ]; then
echo "It looks like not all the generator scripts were run,"
echo "did you forget to build the libcxx-generate-files target?"
echo "Did you add all new files it generated?"
false
fi
[libc++] Add a CMake target to re-generate files and revamp CONTRIBUTING.rst As we automate more and more things in the library, it becomes useful for contributors to have a single target for running all the automation as part of their workflow. This commit adds a new `libcxx-generate-files` target that should re-generate all the auto-generated files in the library. As a fly-by, I also revamped the documentation on Contributing to account for this new target and present it as a bullet list of things to check before committing. I also added a few things that are often overlooked to that list, such as updating the synopsis and the status files. Differential Revision: https://reviews.llvm.org/D106067
2021-07-15 10:19:39 -04:00
[libc++][CI] Fix check-generated-output. Before the script detected non-ASCII characters but let them pass. This fixes the issue. I had a way to solve the issue, during review @Quuxplusone suggested a better alternative. The patch has been changed to use this alternative. Intended failed builds: - Not updated generated files https://buildkite.com/llvm-project/libcxx-ci/builds/2822 - Not updated generated files and non-ASCII usage https://buildkite.com/llvm-project/libcxx-ci/builds/2835 - Non-ASCII usage https://buildkite.com/llvm-project/libcxx-ci/builds/2836 Reviewed By: #libc, Quuxplusone, curdeius Differential Revision: https://reviews.llvm.org/D101303
2021-04-28 19:13:52 +02:00
# Reject patches that introduce non-ASCII characters or hard tabs.
[libc++] [test] Recommit the unsetting of LC_COLLATE in the builder script. This re-reverts one piece of 1b885573327d0f6b36f24ad23d243642f658750b, reapplying one piece of D101437 (but not the "service"-queue piece of it). It turns out that the behavior of `grep [^ -~]`, or even `grep [A-Z]`, depends on locale, specifically `LC_COLLATE`. So we want to make sure we're not in any weird locale, no matter what machine we're running on. Yes, "en_US.UTF-8" counts as weird! https://stackoverflow.com/questions/67320156/misbehavior-of-gnu-grep-when-grepping-for-ignores-spaces https://stackoverflow.com/questions/6799872/how-to-make-grep-a-z-independent-of-locale
2021-04-30 14:43:33 -04:00
# Depends on LC_COLLATE set at the top of this script.
[libc++] Extend check for non-ASCII characters to src/, test/ and benchmarks/ Differential Revision: https://reviews.llvm.org/D132180
2022-08-18 17:41:13 -04:00
! grep -rn '[^ -~]' libcxx/include libcxx/src libcxx/test libcxx/benchmarks \
--exclude '*.dat' \
[libc++][chrono] Implements formatter day. This implements the enabled specializaton template<class charT> struct formatter<chrono::day, charT>; and template<class charT, class traits> basic_ostream<charT, traits>& operator<<(basic_ostream<charT, traits>& os, const day& d); Implements: - LWG 3241 chrono-spec grammar ambiguity in §[time.format] Partially implements: - P1361 Integration of chrono with text formatting Reviewed By: #libc, ldionne Differential Revision: https://reviews.llvm.org/D128577
2022-03-20 13:40:02 +01:00
--exclude 'format_tests.h' \
--exclude 'formatter.day.pass.cpp' \
[libc++] Extend check for non-ASCII characters to src/, test/ and benchmarks/ Differential Revision: https://reviews.llvm.org/D132180
2022-08-18 17:41:13 -04:00
--exclude 'grep.pass.cpp' \
--exclude 'locale-specific_form.pass.cpp' \
[libc++][chrono] Implements formatter day. This implements the enabled specializaton template<class charT> struct formatter<chrono::day, charT>; and template<class charT, class traits> basic_ostream<charT, traits>& operator<<(basic_ostream<charT, traits>& os, const day& d); Implements: - LWG 3241 chrono-spec grammar ambiguity in §[time.format] Partially implements: - P1361 Integration of chrono with text formatting Reviewed By: #libc, ldionne Differential Revision: https://reviews.llvm.org/D128577
2022-03-20 13:40:02 +01:00
--exclude 'std_format_spec_string_unicode.bench.cpp' \
|| false
[libc++] Add a CMake target to re-generate files and revamp CONTRIBUTING.rst As we automate more and more things in the library, it becomes useful for contributors to have a single target for running all the automation as part of their workflow. This commit adds a new `libcxx-generate-files` target that should re-generate all the auto-generated files in the library. As a fly-by, I also revamped the documentation on Contributing to account for this new target and present it as a bullet list of things to check before committing. I also added a few things that are often overlooked to that list, such as updating the synopsis and the status files. Differential Revision: https://reviews.llvm.org/D106067
2021-07-15 10:19:39 -04:00
[libc++] Remove trailing whitespace from libcxx includes, source, tests and benchmarks Differential Revision: https://reviews.llvm.org/D132175
2022-08-18 16:49:06 -04:00
# Reject code with trailing whitespace
! grep -rn '[[:blank:]]$' libcxx/include libcxx/src libcxx/test libcxx/benchmarks || false
[libc++] [CI] Validate the output of the generated scripts. This adds a CI job validating that the output of utils/generate_feature_test_macro_components.py, libcxx/utils/generate_header_inclusion_tests.py, and utils/generate_header_tests.py are up to date. The validation method has been copied from the Format job. Differential Revision: https://reviews.llvm.org/D99862
2021-04-04 20:11:48 +02:00
;;
[libc++][ci] Add a job to run the vanilla configuration on Apple Previously, we'd only have jobs testing the Apple cache on Apple platforms, but libc++ should also work out-of-the-box.
2020-10-01 13:55:39 -04:00
generic-cxx03)
[libc++] Allow customizing a few paths when running build bots This allows reusing run-buildbot for downstream testing as well.
2020-11-05 19:02:32 -05:00
clean
[libunwind] Tidy-up the testing configuration for libunwind Start testing Apple backdeployment with older libunwinds, and stop explicitly specifying the libunwind testing config, since it is already selected correctly by default. Differential Revision: https://reviews.llvm.org/D126470
2022-05-26 10:19:25 -04:00
generate-cmake -C "${MONOREPO_ROOT}/libcxx/cmake/caches/Generic-cxx03.cmake"
[runtimes][ci] Run the tests for libunwind in the CI We should arguably have always been doing that. The state of libunwind is quite sad, so this commit adds several XFAILs to make the CI pass. We need to investigate why so many tests are not passing in some configurations, but I'll defer that to folks who actually work on libunwind for lack of bandwidth. Differential Revision: https://reviews.llvm.org/D110872
2021-09-30 15:11:48 -04:00
check-runtimes
[libc++] Formalize what configurations are covered by the ABI lists By encoding ABI-affecting properties in the name of the ABI list, it makes it clear when an ABI list test should or should not be available, and what results we should expect. Note that we clearly don't encode all ABI-affecting parameters in the name right now -- I just ported over what we supported in the code that was there previously. As we encounter configurations that we wish to support but produce different ABI lists, we can add those to the ABI identifier and start supporting them. This commit also starts checking the ABI list in the CI jobs that run a supported configuration. Eventually, all configurations should have a generated ABI list and the test should even run implicitly as part of the Lit test suite. Differential Revision: https://reviews.llvm.org/D92194
2020-11-26 15:00:42 -05:00
check-abi-list
[libc++] Initial support for pre-commit CI with Buildkite This commit adds basic files and scripts that are used for the Buildkite pre-commit CI setup. This was tested to mostly work on a fork of llvm-project, however some adjustments will have to be made as we complete the real setup.
2020-09-23 09:20:03 -04:00
;;
[libc++][ci] Add a job to run the vanilla configuration on Apple Previously, we'd only have jobs testing the Apple cache on Apple platforms, but libc++ should also work out-of-the-box.
2020-10-01 13:55:39 -04:00
generic-cxx11)
[libc++] Allow customizing a few paths when running build bots This allows reusing run-buildbot for downstream testing as well.
2020-11-05 19:02:32 -05:00
clean
[libunwind] Tidy-up the testing configuration for libunwind Start testing Apple backdeployment with older libunwinds, and stop explicitly specifying the libunwind testing config, since it is already selected correctly by default. Differential Revision: https://reviews.llvm.org/D126470
2022-05-26 10:19:25 -04:00
generate-cmake -C "${MONOREPO_ROOT}/libcxx/cmake/caches/Generic-cxx11.cmake"
[runtimes][ci] Run the tests for libunwind in the CI We should arguably have always been doing that. The state of libunwind is quite sad, so this commit adds several XFAILs to make the CI pass. We need to investigate why so many tests are not passing in some configurations, but I'll defer that to folks who actually work on libunwind for lack of bandwidth. Differential Revision: https://reviews.llvm.org/D110872
2021-09-30 15:11:48 -04:00
check-runtimes
[libc++] Formalize what configurations are covered by the ABI lists By encoding ABI-affecting properties in the name of the ABI list, it makes it clear when an ABI list test should or should not be available, and what results we should expect. Note that we clearly don't encode all ABI-affecting parameters in the name right now -- I just ported over what we supported in the code that was there previously. As we encounter configurations that we wish to support but produce different ABI lists, we can add those to the ABI identifier and start supporting them. This commit also starts checking the ABI list in the CI jobs that run a supported configuration. Eventually, all configurations should have a generated ABI list and the test should even run implicitly as part of the Lit test suite. Differential Revision: https://reviews.llvm.org/D92194
2020-11-26 15:00:42 -05:00
check-abi-list
[libc++] Initial support for pre-commit CI with Buildkite This commit adds basic files and scripts that are used for the Buildkite pre-commit CI setup. This was tested to mostly work on a fork of llvm-project, however some adjustments will have to be made as we complete the real setup.
2020-09-23 09:20:03 -04:00
;;
[libc++][ci] Add a job to run the vanilla configuration on Apple Previously, we'd only have jobs testing the Apple cache on Apple platforms, but libc++ should also work out-of-the-box.
2020-10-01 13:55:39 -04:00
generic-cxx14)
[libc++] Allow customizing a few paths when running build bots This allows reusing run-buildbot for downstream testing as well.
2020-11-05 19:02:32 -05:00
clean
[libunwind] Tidy-up the testing configuration for libunwind Start testing Apple backdeployment with older libunwinds, and stop explicitly specifying the libunwind testing config, since it is already selected correctly by default. Differential Revision: https://reviews.llvm.org/D126470
2022-05-26 10:19:25 -04:00
generate-cmake -C "${MONOREPO_ROOT}/libcxx/cmake/caches/Generic-cxx14.cmake"
[runtimes][ci] Run the tests for libunwind in the CI We should arguably have always been doing that. The state of libunwind is quite sad, so this commit adds several XFAILs to make the CI pass. We need to investigate why so many tests are not passing in some configurations, but I'll defer that to folks who actually work on libunwind for lack of bandwidth. Differential Revision: https://reviews.llvm.org/D110872
2021-09-30 15:11:48 -04:00
check-runtimes
[libc++] Formalize what configurations are covered by the ABI lists By encoding ABI-affecting properties in the name of the ABI list, it makes it clear when an ABI list test should or should not be available, and what results we should expect. Note that we clearly don't encode all ABI-affecting parameters in the name right now -- I just ported over what we supported in the code that was there previously. As we encounter configurations that we wish to support but produce different ABI lists, we can add those to the ABI identifier and start supporting them. This commit also starts checking the ABI list in the CI jobs that run a supported configuration. Eventually, all configurations should have a generated ABI list and the test should even run implicitly as part of the Lit test suite. Differential Revision: https://reviews.llvm.org/D92194
2020-11-26 15:00:42 -05:00
check-abi-list
[libc++] Initial support for pre-commit CI with Buildkite This commit adds basic files and scripts that are used for the Buildkite pre-commit CI setup. This was tested to mostly work on a fork of llvm-project, however some adjustments will have to be made as we complete the real setup.
2020-09-23 09:20:03 -04:00
;;
[libc++][ci] Add a job to run the vanilla configuration on Apple Previously, we'd only have jobs testing the Apple cache on Apple platforms, but libc++ should also work out-of-the-box.
2020-10-01 13:55:39 -04:00
generic-cxx17)
[libc++] Allow customizing a few paths when running build bots This allows reusing run-buildbot for downstream testing as well.
2020-11-05 19:02:32 -05:00
clean
[libunwind] Tidy-up the testing configuration for libunwind Start testing Apple backdeployment with older libunwinds, and stop explicitly specifying the libunwind testing config, since it is already selected correctly by default. Differential Revision: https://reviews.llvm.org/D126470
2022-05-26 10:19:25 -04:00
generate-cmake -C "${MONOREPO_ROOT}/libcxx/cmake/caches/Generic-cxx17.cmake"
[runtimes][ci] Run the tests for libunwind in the CI We should arguably have always been doing that. The state of libunwind is quite sad, so this commit adds several XFAILs to make the CI pass. We need to investigate why so many tests are not passing in some configurations, but I'll defer that to folks who actually work on libunwind for lack of bandwidth. Differential Revision: https://reviews.llvm.org/D110872
2021-09-30 15:11:48 -04:00
check-runtimes
[libc++] Formalize what configurations are covered by the ABI lists By encoding ABI-affecting properties in the name of the ABI list, it makes it clear when an ABI list test should or should not be available, and what results we should expect. Note that we clearly don't encode all ABI-affecting parameters in the name right now -- I just ported over what we supported in the code that was there previously. As we encounter configurations that we wish to support but produce different ABI lists, we can add those to the ABI identifier and start supporting them. This commit also starts checking the ABI list in the CI jobs that run a supported configuration. Eventually, all configurations should have a generated ABI list and the test should even run implicitly as part of the Lit test suite. Differential Revision: https://reviews.llvm.org/D92194
2020-11-26 15:00:42 -05:00
check-abi-list
[libc++] Initial support for pre-commit CI with Buildkite This commit adds basic files and scripts that are used for the Buildkite pre-commit CI setup. This was tested to mostly work on a fork of llvm-project, however some adjustments will have to be made as we complete the real setup.
2020-09-23 09:20:03 -04:00
;;
[libc++] Use c++20 instead of c++2a consistently. * The only exception is that the flag -std=c++2a is still used not to break compatibility with older compilers (clang <= 9, gcc <= 9). * Bump _LIBCPP_STD_VER for C++20 to 20 and use 21 for the future standard (C++2b). That's a preparation step to add c++2b support to libc++. Reviewed By: ldionne, #libc Differential Revision: https://reviews.llvm.org/D93383
2021-01-07 12:29:04 +01:00
generic-cxx20)
[libc++] Allow customizing a few paths when running build bots This allows reusing run-buildbot for downstream testing as well.
2020-11-05 19:02:32 -05:00
clean
[libunwind] Tidy-up the testing configuration for libunwind Start testing Apple backdeployment with older libunwinds, and stop explicitly specifying the libunwind testing config, since it is already selected correctly by default. Differential Revision: https://reviews.llvm.org/D126470
2022-05-26 10:19:25 -04:00
generate-cmake -C "${MONOREPO_ROOT}/libcxx/cmake/caches/Generic-cxx20.cmake"
[runtimes][ci] Run the tests for libunwind in the CI We should arguably have always been doing that. The state of libunwind is quite sad, so this commit adds several XFAILs to make the CI pass. We need to investigate why so many tests are not passing in some configurations, but I'll defer that to folks who actually work on libunwind for lack of bandwidth. Differential Revision: https://reviews.llvm.org/D110872
2021-09-30 15:11:48 -04:00
check-runtimes
[libc++] Add basic support for -std=c++2b. * Add feature test macros. * Add buildbot configuration generic-cxx2b that uses clang-tot. Reviewed By: ldionne, #libc Differential Revision: https://reviews.llvm.org/D94227
2021-01-08 18:40:42 +01:00
check-abi-list
;;
generic-cxx2b)
clean
[libunwind] Tidy-up the testing configuration for libunwind Start testing Apple backdeployment with older libunwinds, and stop explicitly specifying the libunwind testing config, since it is already selected correctly by default. Differential Revision: https://reviews.llvm.org/D126470
2022-05-26 10:19:25 -04:00
generate-cmake -C "${MONOREPO_ROOT}/libcxx/cmake/caches/Generic-cxx2b.cmake"
[runtimes][ci] Run the tests for libunwind in the CI We should arguably have always been doing that. The state of libunwind is quite sad, so this commit adds several XFAILs to make the CI pass. We need to investigate why so many tests are not passing in some configurations, but I'll defer that to folks who actually work on libunwind for lack of bandwidth. Differential Revision: https://reviews.llvm.org/D110872
2021-09-30 15:11:48 -04:00
check-runtimes
[libc++] Formalize what configurations are covered by the ABI lists By encoding ABI-affecting properties in the name of the ABI list, it makes it clear when an ABI list test should or should not be available, and what results we should expect. Note that we clearly don't encode all ABI-affecting parameters in the name right now -- I just ported over what we supported in the code that was there previously. As we encounter configurations that we wish to support but produce different ABI lists, we can add those to the ABI identifier and start supporting them. This commit also starts checking the ABI list in the CI jobs that run a supported configuration. Eventually, all configurations should have a generated ABI list and the test should even run implicitly as part of the Lit test suite. Differential Revision: https://reviews.llvm.org/D92194
2020-11-26 15:00:42 -05:00
check-abi-list
[libc++] Initial support for pre-commit CI with Buildkite This commit adds basic files and scripts that are used for the Buildkite pre-commit CI setup. This was tested to mostly work on a fork of llvm-project, however some adjustments will have to be made as we complete the real setup.
2020-09-23 09:20:03 -04:00
;;
[libc++] Fix libc++ build with assertions enabled This fixes http://llvm.org/PR50534. This is another take on D103960 which is less disruptive. Differential Revision: https://reviews.llvm.org/D103964
2021-06-09 09:41:27 -04:00
generic-assertions)
clean
[libunwind] Tidy-up the testing configuration for libunwind Start testing Apple backdeployment with older libunwinds, and stop explicitly specifying the libunwind testing config, since it is already selected correctly by default. Differential Revision: https://reviews.llvm.org/D126470
2022-05-26 10:19:25 -04:00
generate-cmake -C "${MONOREPO_ROOT}/libcxx/cmake/caches/Generic-assertions.cmake"
[runtimes][ci] Run the tests for libunwind in the CI We should arguably have always been doing that. The state of libunwind is quite sad, so this commit adds several XFAILs to make the CI pass. We need to investigate why so many tests are not passing in some configurations, but I'll defer that to folks who actually work on libunwind for lack of bandwidth. Differential Revision: https://reviews.llvm.org/D110872
2021-09-30 15:11:48 -04:00
check-runtimes
[libc++] Fix libc++ build with assertions enabled This fixes http://llvm.org/PR50534. This is another take on D103960 which is less disruptive. Differential Revision: https://reviews.llvm.org/D103964
2021-06-09 09:41:27 -04:00
check-abi-list
;;
[libc++] Make the Debug mode a configuration-time only option The debug mode has been broken pretty much ever since it was shipped because it was possible to enable the debug mode in user code without actually enabling it in the dylib, leading to ODR violations that caused various kinds of failures. This commit makes the debug mode a knob that is configured when building the library and which can't be changed afterwards. This is less flexible for users, however it will actually work as intended and it will allow us, in the future, to add various kinds of checks that do not assume the same ABI as the normal library. Furthermore, this will make the debug mode more robust, which means that vendors might be more tempted to support it properly, which hasn't been the case with the current debug mode. This patch shouldn't break any user code, except folks who are building against a library that doesn't have the debug mode enabled and who try to enable the debug mode in their code. Such users will get a compile-time error explaining that this configuration isn't supported anymore. In the future, we should further increase the granularity of the debug mode checks so that we can cherry-pick which checks to enable, like we do for unspecified behavior randomization. Differential Revision: https://reviews.llvm.org/D122941
2022-04-01 16:38:30 -04:00
generic-debug-mode)
[libc++] [test] Add a debug-mode CI. To run llvm-lit manually from the command line: ./bin/llvm-lit -sv --param std=c++2b --param cxx_under_test=`pwd`/bin/clang \ --param debug_level=1 ../libcxx/test/ Tests that currently fail with `debug_level=1` are marked `LIBCXX-DEBUG-FIXME`, but my intent is to deal with all of them and leave no such annotations in the codebase within the next couple weeks. (I have patches for all of them in my local checkout.) Differential Revision: https://reviews.llvm.org/D100866
2021-04-20 11:27:03 -04:00
clean
[libc++] Make the Debug mode a configuration-time only option The debug mode has been broken pretty much ever since it was shipped because it was possible to enable the debug mode in user code without actually enabling it in the dylib, leading to ODR violations that caused various kinds of failures. This commit makes the debug mode a knob that is configured when building the library and which can't be changed afterwards. This is less flexible for users, however it will actually work as intended and it will allow us, in the future, to add various kinds of checks that do not assume the same ABI as the normal library. Furthermore, this will make the debug mode more robust, which means that vendors might be more tempted to support it properly, which hasn't been the case with the current debug mode. This patch shouldn't break any user code, except folks who are building against a library that doesn't have the debug mode enabled and who try to enable the debug mode in their code. Such users will get a compile-time error explaining that this configuration isn't supported anymore. In the future, we should further increase the granularity of the debug mode checks so that we can cherry-pick which checks to enable, like we do for unspecified behavior randomization. Differential Revision: https://reviews.llvm.org/D122941
2022-04-01 16:38:30 -04:00
generate-cmake -C "${MONOREPO_ROOT}/libcxx/cmake/caches/Generic-debug-mode.cmake"
[runtimes][ci] Run the tests for libunwind in the CI We should arguably have always been doing that. The state of libunwind is quite sad, so this commit adds several XFAILs to make the CI pass. We need to investigate why so many tests are not passing in some configurations, but I'll defer that to folks who actually work on libunwind for lack of bandwidth. Differential Revision: https://reviews.llvm.org/D110872
2021-09-30 15:11:48 -04:00
check-runtimes
[libc++] Drop the legacy debug mode symbols by default 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
2022-07-19 11:04:31 -04:00
# We don't check the ABI lists because the debug mode ABI is not stable
[libc++] [test] Add a debug-mode CI. To run llvm-lit manually from the command line: ./bin/llvm-lit -sv --param std=c++2b --param cxx_under_test=`pwd`/bin/clang \ --param debug_level=1 ../libcxx/test/ Tests that currently fail with `debug_level=1` are marked `LIBCXX-DEBUG-FIXME`, but my intent is to deal with all of them and leave no such annotations in the codebase within the next couple weeks. (I have patches for all of them in my local checkout.) Differential Revision: https://reviews.llvm.org/D100866
2021-04-20 11:27:03 -04:00
;;
[libc++][ci] Add a job to run the vanilla configuration on Apple Previously, we'd only have jobs testing the Apple cache on Apple platforms, but libc++ should also work out-of-the-box.
2020-10-01 13:55:39 -04:00
generic-noexceptions)
[libc++] Allow customizing a few paths when running build bots This allows reusing run-buildbot for downstream testing as well.
2020-11-05 19:02:32 -05:00
clean
[libunwind] Tidy-up the testing configuration for libunwind Start testing Apple backdeployment with older libunwinds, and stop explicitly specifying the libunwind testing config, since it is already selected correctly by default. Differential Revision: https://reviews.llvm.org/D126470
2022-05-26 10:19:25 -04:00
generate-cmake -C "${MONOREPO_ROOT}/libcxx/cmake/caches/Generic-noexceptions.cmake"
[runtimes][ci] Run the tests for libunwind in the CI We should arguably have always been doing that. The state of libunwind is quite sad, so this commit adds several XFAILs to make the CI pass. We need to investigate why so many tests are not passing in some configurations, but I'll defer that to folks who actually work on libunwind for lack of bandwidth. Differential Revision: https://reviews.llvm.org/D110872
2021-09-30 15:11:48 -04:00
check-runtimes
[libc++] Take more knobs into account when generating ABI lists This change will make it possible to track exported symbols in more configurations, notably the Apple system one, where we disable incomplete features and the debug mode. Also, as a fly-by fix, shorten the name for whether new is in libc++ or not. Differential Revision: https://reviews.llvm.org/D119764
2022-02-14 14:39:17 -05:00
check-abi-list
[libc++] Initial support for pre-commit CI with Buildkite This commit adds basic files and scripts that are used for the Buildkite pre-commit CI setup. This was tested to mostly work on a fork of llvm-project, however some adjustments will have to be made as we complete the real setup.
2020-09-23 09:20:03 -04:00
;;
[libc++] Add a CI configuration for the modular build Differential Revision: https://reviews.llvm.org/D103559
2021-06-02 17:07:57 -04:00
generic-modules)
clean
[libunwind] Tidy-up the testing configuration for libunwind Start testing Apple backdeployment with older libunwinds, and stop explicitly specifying the libunwind testing config, since it is already selected correctly by default. Differential Revision: https://reviews.llvm.org/D126470
2022-05-26 10:19:25 -04:00
generate-cmake -C "${MONOREPO_ROOT}/libcxx/cmake/caches/Generic-modules.cmake"
[runtimes][ci] Run the tests for libunwind in the CI We should arguably have always been doing that. The state of libunwind is quite sad, so this commit adds several XFAILs to make the CI pass. We need to investigate why so many tests are not passing in some configurations, but I'll defer that to folks who actually work on libunwind for lack of bandwidth. Differential Revision: https://reviews.llvm.org/D110872
2021-09-30 15:11:48 -04:00
check-runtimes
[libc++] Take more knobs into account when generating ABI lists This change will make it possible to track exported symbols in more configurations, notably the Apple system one, where we disable incomplete features and the debug mode. Also, as a fly-by fix, shorten the name for whether new is in libc++ or not. Differential Revision: https://reviews.llvm.org/D119764
2022-02-14 14:39:17 -05:00
check-abi-list
[libc++] Add a CI configuration for the modular build Differential Revision: https://reviews.llvm.org/D103559
2021-06-02 17:07:57 -04:00
;;
[libc++] Add a CI configuration with static libc++/libc++abi Differential Revision: https://reviews.llvm.org/D99268
2021-03-24 09:50:59 -04:00
generic-static)
clean
[libunwind] Tidy-up the testing configuration for libunwind Start testing Apple backdeployment with older libunwinds, and stop explicitly specifying the libunwind testing config, since it is already selected correctly by default. Differential Revision: https://reviews.llvm.org/D126470
2022-05-26 10:19:25 -04:00
generate-cmake -C "${MONOREPO_ROOT}/libcxx/cmake/caches/Generic-static.cmake"
[runtimes][ci] Run the tests for libunwind in the CI We should arguably have always been doing that. The state of libunwind is quite sad, so this commit adds several XFAILs to make the CI pass. We need to investigate why so many tests are not passing in some configurations, but I'll defer that to folks who actually work on libunwind for lack of bandwidth. Differential Revision: https://reviews.llvm.org/D110872
2021-09-30 15:11:48 -04:00
check-runtimes
[libc++] Add a CI configuration with static libc++/libc++abi Differential Revision: https://reviews.llvm.org/D99268
2021-03-24 09:50:59 -04:00
;;
[runtimes] Fix the build of merged ABI/unwinder libraries Also, add a CI job that tests this configuration. The exact configuration is that we build a shared libc++ and merge objects for the ABI library and the unwinder library into it. Differential Revision: https://reviews.llvm.org/D125903
2022-05-18 12:05:45 -04:00
generic-merged)
clean
generate-cmake -C "${MONOREPO_ROOT}/libcxx/cmake/caches/Generic-merged.cmake" \
-DLIBCXX_TEST_CONFIG="llvm-libc++-shared.cfg.in" \
-DLIBCXXABI_TEST_CONFIG="llvm-libc++abi-merged.cfg.in" \
-DLIBUNWIND_TEST_CONFIG="llvm-libunwind-merged.cfg.in"
check-runtimes
;;
[libc++][ci] Add a job to run the vanilla configuration on Apple Previously, we'd only have jobs testing the Apple cache on Apple platforms, but libc++ should also work out-of-the-box.
2020-10-01 13:55:39 -04:00
generic-gcc)
[libc++] Allow customizing a few paths when running build bots This allows reusing run-buildbot for downstream testing as well.
2020-11-05 19:02:32 -05:00
clean
[libunwind] Tidy-up the testing configuration for libunwind Start testing Apple backdeployment with older libunwinds, and stop explicitly specifying the libunwind testing config, since it is already selected correctly by default. Differential Revision: https://reviews.llvm.org/D126470
2022-05-26 10:19:25 -04:00
generate-cmake -DLIBCXX_ENABLE_WERROR=NO \
[libcxx] [ci] Enable -Werror for libcxxabi and libunwind too Differential Revision: https://reviews.llvm.org/D122800
2022-03-31 11:51:30 +03:00
-DLIBCXXABI_ENABLE_WERROR=NO \
-DLIBUNWIND_ENABLE_WERROR=NO
[runtimes][ci] Run the tests for libunwind in the CI We should arguably have always been doing that. The state of libunwind is quite sad, so this commit adds several XFAILs to make the CI pass. We need to investigate why so many tests are not passing in some configurations, but I'll defer that to folks who actually work on libunwind for lack of bandwidth. Differential Revision: https://reviews.llvm.org/D110872
2021-09-30 15:11:48 -04:00
check-runtimes
[libc++] Initial support for pre-commit CI with Buildkite This commit adds basic files and scripts that are used for the Buildkite pre-commit CI setup. This was tested to mostly work on a fork of llvm-project, however some adjustments will have to be made as we complete the real setup.
2020-09-23 09:20:03 -04:00
;;
[libc++] Add a job running GCC with C++11 This configuration is interesting because GCC has a different level of strictness for some C++ rules. In particular, it implements the older standards more stringently than Clang, which can help find places where we are non-conforming (especially in the test suite). Differential Revision: https://reviews.llvm.org/D105936
2021-07-15 09:46:36 -04:00
generic-gcc-cxx11)
clean
[libc++] Add a from-scratch testing config for GCC Differential Revision: https://reviews.llvm.org/D111329
2021-10-07 14:54:14 -04:00
generate-cmake -C "${MONOREPO_ROOT}/libcxx/cmake/caches/Generic-cxx11.cmake" \
[libcxx] [ci] Enable -Werror for libcxxabi and libunwind too Differential Revision: https://reviews.llvm.org/D122800
2022-03-31 11:51:30 +03:00
-DLIBCXX_ENABLE_WERROR=NO \
-DLIBCXXABI_ENABLE_WERROR=NO \
-DLIBUNWIND_ENABLE_WERROR=NO
[runtimes][ci] Run the tests for libunwind in the CI We should arguably have always been doing that. The state of libunwind is quite sad, so this commit adds several XFAILs to make the CI pass. We need to investigate why so many tests are not passing in some configurations, but I'll defer that to folks who actually work on libunwind for lack of bandwidth. Differential Revision: https://reviews.llvm.org/D110872
2021-09-30 15:11:48 -04:00
check-runtimes
[libc++] Add a job running GCC with C++11 This configuration is interesting because GCC has a different level of strictness for some C++ rules. In particular, it implements the older standards more stringently than Clang, which can help find places where we are non-conforming (especially in the test suite). Differential Revision: https://reviews.llvm.org/D105936
2021-07-15 09:46:36 -04:00
;;
[libc++][ci] Add a job to run the vanilla configuration on Apple Previously, we'd only have jobs testing the Apple cache on Apple platforms, but libc++ should also work out-of-the-box.
2020-10-01 13:55:39 -04:00
generic-asan)
[libc++] Allow customizing a few paths when running build bots This allows reusing run-buildbot for downstream testing as well.
2020-11-05 19:02:32 -05:00
clean
[libunwind] Tidy-up the testing configuration for libunwind Start testing Apple backdeployment with older libunwinds, and stop explicitly specifying the libunwind testing config, since it is already selected correctly by default. Differential Revision: https://reviews.llvm.org/D126470
2022-05-26 10:19:25 -04:00
generate-cmake -C "${MONOREPO_ROOT}/libcxx/cmake/caches/Generic-asan.cmake"
[runtimes][ci] Run the tests for libunwind in the CI We should arguably have always been doing that. The state of libunwind is quite sad, so this commit adds several XFAILs to make the CI pass. We need to investigate why so many tests are not passing in some configurations, but I'll defer that to folks who actually work on libunwind for lack of bandwidth. Differential Revision: https://reviews.llvm.org/D110872
2021-09-30 15:11:48 -04:00
check-runtimes
[libc++] Initial support for pre-commit CI with Buildkite This commit adds basic files and scripts that are used for the Buildkite pre-commit CI setup. This was tested to mostly work on a fork of llvm-project, however some adjustments will have to be made as we complete the real setup.
2020-09-23 09:20:03 -04:00
;;
[libc++][ci] Add a job to run the vanilla configuration on Apple Previously, we'd only have jobs testing the Apple cache on Apple platforms, but libc++ should also work out-of-the-box.
2020-10-01 13:55:39 -04:00
generic-msan)
[libc++] Allow customizing a few paths when running build bots This allows reusing run-buildbot for downstream testing as well.
2020-11-05 19:02:32 -05:00
clean
[libunwind] Tidy-up the testing configuration for libunwind Start testing Apple backdeployment with older libunwinds, and stop explicitly specifying the libunwind testing config, since it is already selected correctly by default. Differential Revision: https://reviews.llvm.org/D126470
2022-05-26 10:19:25 -04:00
generate-cmake -C "${MONOREPO_ROOT}/libcxx/cmake/caches/Generic-msan.cmake"
[runtimes][ci] Run the tests for libunwind in the CI We should arguably have always been doing that. The state of libunwind is quite sad, so this commit adds several XFAILs to make the CI pass. We need to investigate why so many tests are not passing in some configurations, but I'll defer that to folks who actually work on libunwind for lack of bandwidth. Differential Revision: https://reviews.llvm.org/D110872
2021-09-30 15:11:48 -04:00
check-runtimes
[libc++] Initial support for pre-commit CI with Buildkite This commit adds basic files and scripts that are used for the Buildkite pre-commit CI setup. This was tested to mostly work on a fork of llvm-project, however some adjustments will have to be made as we complete the real setup.
2020-09-23 09:20:03 -04:00
;;
[libc++][ci] Add a job to run the vanilla configuration on Apple Previously, we'd only have jobs testing the Apple cache on Apple platforms, but libc++ should also work out-of-the-box.
2020-10-01 13:55:39 -04:00
generic-tsan)
[libc++] Allow customizing a few paths when running build bots This allows reusing run-buildbot for downstream testing as well.
2020-11-05 19:02:32 -05:00
clean
[libunwind] Tidy-up the testing configuration for libunwind Start testing Apple backdeployment with older libunwinds, and stop explicitly specifying the libunwind testing config, since it is already selected correctly by default. Differential Revision: https://reviews.llvm.org/D126470
2022-05-26 10:19:25 -04:00
generate-cmake -C "${MONOREPO_ROOT}/libcxx/cmake/caches/Generic-tsan.cmake"
[runtimes][ci] Run the tests for libunwind in the CI We should arguably have always been doing that. The state of libunwind is quite sad, so this commit adds several XFAILs to make the CI pass. We need to investigate why so many tests are not passing in some configurations, but I'll defer that to folks who actually work on libunwind for lack of bandwidth. Differential Revision: https://reviews.llvm.org/D110872
2021-09-30 15:11:48 -04:00
check-runtimes
[libc++] Initial support for pre-commit CI with Buildkite This commit adds basic files and scripts that are used for the Buildkite pre-commit CI setup. This was tested to mostly work on a fork of llvm-project, however some adjustments will have to be made as we complete the real setup.
2020-09-23 09:20:03 -04:00
;;
[libc++][ci] Add a job to run the vanilla configuration on Apple Previously, we'd only have jobs testing the Apple cache on Apple platforms, but libc++ should also work out-of-the-box.
2020-10-01 13:55:39 -04:00
generic-ubsan)
[libc++] Allow customizing a few paths when running build bots This allows reusing run-buildbot for downstream testing as well.
2020-11-05 19:02:32 -05:00
clean
[libunwind] Tidy-up the testing configuration for libunwind Start testing Apple backdeployment with older libunwinds, and stop explicitly specifying the libunwind testing config, since it is already selected correctly by default. Differential Revision: https://reviews.llvm.org/D126470
2022-05-26 10:19:25 -04:00
generate-cmake -C "${MONOREPO_ROOT}/libcxx/cmake/caches/Generic-ubsan.cmake"
[runtimes][ci] Run the tests for libunwind in the CI We should arguably have always been doing that. The state of libunwind is quite sad, so this commit adds several XFAILs to make the CI pass. We need to investigate why so many tests are not passing in some configurations, but I'll defer that to folks who actually work on libunwind for lack of bandwidth. Differential Revision: https://reviews.llvm.org/D110872
2021-09-30 15:11:48 -04:00
check-runtimes
[libc++] Initial support for pre-commit CI with Buildkite This commit adds basic files and scripts that are used for the Buildkite pre-commit CI setup. This was tested to mostly work on a fork of llvm-project, however some adjustments will have to be made as we complete the real setup.
2020-09-23 09:20:03 -04:00
;;
[libc++][ci] Add a job to run the vanilla configuration on Apple Previously, we'd only have jobs testing the Apple cache on Apple platforms, but libc++ should also work out-of-the-box.
2020-10-01 13:55:39 -04:00
generic-with_llvm_unwinder)
[libc++] Allow customizing a few paths when running build bots This allows reusing run-buildbot for downstream testing as well.
2020-11-05 19:02:32 -05:00
clean
[libunwind] Tidy-up the testing configuration for libunwind Start testing Apple backdeployment with older libunwinds, and stop explicitly specifying the libunwind testing config, since it is already selected correctly by default. Differential Revision: https://reviews.llvm.org/D126470
2022-05-26 10:19:25 -04:00
generate-cmake -DLIBCXXABI_USE_LLVM_UNWINDER=ON
[runtimes][ci] Run the tests for libunwind in the CI We should arguably have always been doing that. The state of libunwind is quite sad, so this commit adds several XFAILs to make the CI pass. We need to investigate why so many tests are not passing in some configurations, but I'll defer that to folks who actually work on libunwind for lack of bandwidth. Differential Revision: https://reviews.llvm.org/D110872
2021-09-30 15:11:48 -04:00
check-runtimes
[libc++] Initial support for pre-commit CI with Buildkite This commit adds basic files and scripts that are used for the Buildkite pre-commit CI setup. This was tested to mostly work on a fork of llvm-project, however some adjustments will have to be made as we complete the real setup.
2020-09-23 09:20:03 -04:00
;;
[libc++] Re-add transitive includes that had been removed since LLVM 14 This commit re-adds transitive includes that had been removed by 4cd04d1687f1, c36870c8e79c, a83f4b9cda57, 1458458b558d, 2e2f3158c604, and 489637e66dd3. This should cover almost all the includes that had been removed since LLVM 14 and that would contribute to breaking user code when releasing LLVM 15. It is possible to disable the inclusion of these headers by defining _LIBCPP_REMOVE_TRANSITIVE_INCLUDES. The intent is that vendors will enable that macro and start fixing downstream issues immediately. We can then remove the macro (and the transitive includes) by default in a future release. That way, we will break users only once by removing transitive includes in bulk instead of doing it bit by bit a every release, which is more disruptive for users. Note 1: The set of headers to re-add was found by re-generating the transitive include test on a checkout of release/14.x, which provided the list of all transitive includes we used to provide. Note 2: Several includes of <vector>, <optional>, <array> and <unordered_map> have been added in this commit. These transitive inclusions were added when we implemented boyer_moore_searcher in <functional>. Note 3: This is a best effort patch to try and resolve downstream breakage caused since branching LLVM 14. I wasn't able to perfectly mirror transitive includes in LLVM 14 for a few headers, so I added a release note explaining it. To summarize, adding boyer_moore_searcher created a bunch of circular dependencies, so we have to break backwards compatibility in a few cases. Differential Revision: https://reviews.llvm.org/D128661
2022-06-27 15:53:41 -04:00
generic-no-transitive-includes)
clean
generate-cmake -C "${MONOREPO_ROOT}/libcxx/cmake/caches/Generic-no-transitive-includes.cmake"
check-runtimes
;;
[libc++] Rename the generic-singlethreaded CI job to generic-no-threads for consistency
2022-05-24 09:58:04 -04:00
generic-no-threads)
[libc++] Allow customizing a few paths when running build bots This allows reusing run-buildbot for downstream testing as well.
2020-11-05 19:02:32 -05:00
clean
[libunwind] Tidy-up the testing configuration for libunwind Start testing Apple backdeployment with older libunwinds, and stop explicitly specifying the libunwind testing config, since it is already selected correctly by default. Differential Revision: https://reviews.llvm.org/D126470
2022-05-26 10:19:25 -04:00
generate-cmake -C "${MONOREPO_ROOT}/libcxx/cmake/caches/Generic-no-threads.cmake"
[runtimes][ci] Run the tests for libunwind in the CI We should arguably have always been doing that. The state of libunwind is quite sad, so this commit adds several XFAILs to make the CI pass. We need to investigate why so many tests are not passing in some configurations, but I'll defer that to folks who actually work on libunwind for lack of bandwidth. Differential Revision: https://reviews.llvm.org/D110872
2021-09-30 15:11:48 -04:00
check-runtimes
[libc++] Initial support for pre-commit CI with Buildkite This commit adds basic files and scripts that are used for the Buildkite pre-commit CI setup. This was tested to mostly work on a fork of llvm-project, however some adjustments will have to be made as we complete the real setup.
2020-09-23 09:20:03 -04:00
;;
[libc++] Make LIBCXX_ENABLE_FILESYSTEM fully consistent Previously, LIBCXX_ENABLE_FILESYSTEM controlled only whether the filesystem support was compiled into libc++'s library. This commit promotes the setting to a first-class option like LIBCXX_ENABLE_LOCALIZATION, where the whole library is aware of the setting and features that depend on <filesystem> won't be provided at all. The test suite is also properly annotated such that tests that depend on <filesystem> are disabled when the library doesn't support it. This is an alternative to https://llvm.org/D94824, but also an improvement along the lines of LIBCXX_ENABLE_LOCALIZATION that I had been wanting to make for a while. Differential Revision: https://reviews.llvm.org/D94921
2021-01-18 12:18:18 -05:00
generic-no-filesystem)
clean
[libunwind] Tidy-up the testing configuration for libunwind Start testing Apple backdeployment with older libunwinds, and stop explicitly specifying the libunwind testing config, since it is already selected correctly by default. Differential Revision: https://reviews.llvm.org/D126470
2022-05-26 10:19:25 -04:00
generate-cmake -C "${MONOREPO_ROOT}/libcxx/cmake/caches/Generic-no-filesystem.cmake"
[runtimes][ci] Run the tests for libunwind in the CI We should arguably have always been doing that. The state of libunwind is quite sad, so this commit adds several XFAILs to make the CI pass. We need to investigate why so many tests are not passing in some configurations, but I'll defer that to folks who actually work on libunwind for lack of bandwidth. Differential Revision: https://reviews.llvm.org/D110872
2021-09-30 15:11:48 -04:00
check-runtimes
[libc++] Make LIBCXX_ENABLE_FILESYSTEM fully consistent Previously, LIBCXX_ENABLE_FILESYSTEM controlled only whether the filesystem support was compiled into libc++'s library. This commit promotes the setting to a first-class option like LIBCXX_ENABLE_LOCALIZATION, where the whole library is aware of the setting and features that depend on <filesystem> won't be provided at all. The test suite is also properly annotated such that tests that depend on <filesystem> are disabled when the library doesn't support it. This is an alternative to https://llvm.org/D94824, but also an improvement along the lines of LIBCXX_ENABLE_LOCALIZATION that I had been wanting to make for a while. Differential Revision: https://reviews.llvm.org/D94921
2021-01-18 12:18:18 -05:00
;;
[libc++] Allow building libc++ on platforms without a random device Some platforms, like several embedded platforms, do not provide a source of randomness through a random device. This commit makes it possible to build and test libc++ for such platforms, i.e. without std::random_device. Surprisingly, the only functionality that doesn't work on such platforms is std::random_device itself -- everything else in <random> still works, one just has to find alternative ways to seed the PRNGs.
2020-10-15 10:32:09 -04:00
generic-no-random_device)
[libc++] Allow customizing a few paths when running build bots This allows reusing run-buildbot for downstream testing as well.
2020-11-05 19:02:32 -05:00
clean
[libunwind] Tidy-up the testing configuration for libunwind Start testing Apple backdeployment with older libunwinds, and stop explicitly specifying the libunwind testing config, since it is already selected correctly by default. Differential Revision: https://reviews.llvm.org/D126470
2022-05-26 10:19:25 -04:00
generate-cmake -C "${MONOREPO_ROOT}/libcxx/cmake/caches/Generic-no-random_device.cmake"
[runtimes][ci] Run the tests for libunwind in the CI We should arguably have always been doing that. The state of libunwind is quite sad, so this commit adds several XFAILs to make the CI pass. We need to investigate why so many tests are not passing in some configurations, but I'll defer that to folks who actually work on libunwind for lack of bandwidth. Differential Revision: https://reviews.llvm.org/D110872
2021-09-30 15:11:48 -04:00
check-runtimes
[libc++] Allow building libc++ on platforms without a random device Some platforms, like several embedded platforms, do not provide a source of randomness through a random device. This commit makes it possible to build and test libc++ for such platforms, i.e. without std::random_device. Surprisingly, the only functionality that doesn't work on such platforms is std::random_device itself -- everything else in <random> still works, one just has to find alternative ways to seed the PRNGs.
2020-10-15 10:32:09 -04:00
;;
[libc++] Add a libc++ configuration that does not support localization When porting libc++ to embedded systems, it can be useful to drop support for localization, which these systems don't implement or care about. Differential Revision: https://reviews.llvm.org/D90072
2020-10-09 15:31:05 -04:00
generic-no-localization)
[libc++] Allow customizing a few paths when running build bots This allows reusing run-buildbot for downstream testing as well.
2020-11-05 19:02:32 -05:00
clean
[libunwind] Tidy-up the testing configuration for libunwind Start testing Apple backdeployment with older libunwinds, and stop explicitly specifying the libunwind testing config, since it is already selected correctly by default. Differential Revision: https://reviews.llvm.org/D126470
2022-05-26 10:19:25 -04:00
generate-cmake -C "${MONOREPO_ROOT}/libcxx/cmake/caches/Generic-no-localization.cmake"
[runtimes][ci] Run the tests for libunwind in the CI We should arguably have always been doing that. The state of libunwind is quite sad, so this commit adds several XFAILs to make the CI pass. We need to investigate why so many tests are not passing in some configurations, but I'll defer that to folks who actually work on libunwind for lack of bandwidth. Differential Revision: https://reviews.llvm.org/D110872
2021-09-30 15:11:48 -04:00
check-runtimes
[libc++] Add a libc++ configuration that does not support localization When porting libc++ to embedded systems, it can be useful to drop support for localization, which these systems don't implement or care about. Differential Revision: https://reviews.llvm.org/D90072
2020-10-09 15:31:05 -04:00
;;
[libc++][format] Add a CMake Unicode option. This option is used to select between the format headers output column width option. This option should be independent of the locale setting. It's encouraged to default to Unicode unless the platform doesn't offer that option. [format.string.std]/10 ``` For the purposes of width computation, a string is assumed to be in a locale-independent, implementation-defined encoding. Implementations should use a Unicode encoding on platforms capable of displaying Unicode ``` Reviewed By: #libc, ldionne, vitaut Differential Revision: https://reviews.llvm.org/D103379
2021-05-25 20:11:08 +02:00
generic-no-unicode)
clean
[libunwind] Tidy-up the testing configuration for libunwind Start testing Apple backdeployment with older libunwinds, and stop explicitly specifying the libunwind testing config, since it is already selected correctly by default. Differential Revision: https://reviews.llvm.org/D126470
2022-05-26 10:19:25 -04:00
generate-cmake -C "${MONOREPO_ROOT}/libcxx/cmake/caches/Generic-no-unicode.cmake"
[runtimes][ci] Run the tests for libunwind in the CI We should arguably have always been doing that. The state of libunwind is quite sad, so this commit adds several XFAILs to make the CI pass. We need to investigate why so many tests are not passing in some configurations, but I'll defer that to folks who actually work on libunwind for lack of bandwidth. Differential Revision: https://reviews.llvm.org/D110872
2021-09-30 15:11:48 -04:00
check-runtimes
[libc++][format] Add a CMake Unicode option. This option is used to select between the format headers output column width option. This option should be independent of the locale setting. It's encouraged to default to Unicode unless the platform doesn't offer that option. [format.string.std]/10 ``` For the purposes of width computation, a string is assumed to be in a locale-independent, implementation-defined encoding. Implementations should use a Unicode encoding on platforms capable of displaying Unicode ``` Reviewed By: #libc, ldionne, vitaut Differential Revision: https://reviews.llvm.org/D103379
2021-05-25 20:11:08 +02:00
;;
[libc++] Add an option to disable wide character support in libc++ Some embedded platforms do not wish to support the C library functionality for handling wchar_t because they have no use for it. It makes sense for libc++ to work properly on those platforms, so this commit adds a carve-out of functionality for wchar_t. Unfortunately, unlike some other carve-outs (e.g. random device), this patch touches several parts of the library. However, despite the wide impact of this patch, I still think it is important to support this configuration since it makes it much simpler to port libc++ to some embedded platforms. Differential Revision: https://reviews.llvm.org/D111265
2021-08-23 15:32:36 -04:00
generic-no-wide-characters)
clean
[libunwind] Tidy-up the testing configuration for libunwind Start testing Apple backdeployment with older libunwinds, and stop explicitly specifying the libunwind testing config, since it is already selected correctly by default. Differential Revision: https://reviews.llvm.org/D126470
2022-05-26 10:19:25 -04:00
generate-cmake -C "${MONOREPO_ROOT}/libcxx/cmake/caches/Generic-no-wide-characters.cmake"
[libc++] Add an option to disable wide character support in libc++ Some embedded platforms do not wish to support the C library functionality for handling wchar_t because they have no use for it. It makes sense for libc++ to work properly on those platforms, so this commit adds a carve-out of functionality for wchar_t. Unfortunately, unlike some other carve-outs (e.g. random device), this patch touches several parts of the library. However, despite the wide impact of this patch, I still think it is important to support this configuration since it makes it much simpler to port libc++ to some embedded platforms. Differential Revision: https://reviews.llvm.org/D111265
2021-08-23 15:32:36 -04:00
check-runtimes
;;
[libc++] Add CI without experimental features and don't exclude span from the tests There is no reason for the parts of std::span that don't depend on ranges to be disabled when ranges aren't provided. Also, to make sure the "no-experimental-stuff" configuration is tested, add a CI job for it. Differential Revision: https://reviews.llvm.org/D118740
2022-02-01 16:32:39 -05:00
generic-no-experimental)
clean
[libunwind] Tidy-up the testing configuration for libunwind Start testing Apple backdeployment with older libunwinds, and stop explicitly specifying the libunwind testing config, since it is already selected correctly by default. Differential Revision: https://reviews.llvm.org/D126470
2022-05-26 10:19:25 -04:00
generate-cmake -C "${MONOREPO_ROOT}/libcxx/cmake/caches/Generic-no-experimental.cmake"
[libc++] Add CI without experimental features and don't exclude span from the tests There is no reason for the parts of std::span that don't depend on ranges to be disabled when ranges aren't provided. Also, to make sure the "no-experimental-stuff" configuration is tested, add a CI job for it. Differential Revision: https://reviews.llvm.org/D118740
2022-02-01 16:32:39 -05:00
check-runtimes
[libc++] Take more knobs into account when generating ABI lists This change will make it possible to track exported symbols in more configurations, notably the Apple system one, where we disable incomplete features and the debug mode. Also, as a fly-by fix, shorten the name for whether new is in libc++ or not. Differential Revision: https://reviews.llvm.org/D119764
2022-02-14 14:39:17 -05:00
check-abi-list
[libc++] Add CI without experimental features and don't exclude span from the tests There is no reason for the parts of std::span that don't depend on ranges to be disabled when ranges aren't provided. Also, to make sure the "no-experimental-stuff" configuration is tested, add a CI job for it. Differential Revision: https://reviews.llvm.org/D118740
2022-02-01 16:32:39 -05:00
;;
[libc++] Add Unstable ABI CI run Reviewed By: ldionne, #libc, Mordante Spies: mgorny, Mordante, libcxx-commits, arichardson Differential Revision: https://reviews.llvm.org/D118725
2022-02-05 14:09:45 +01:00
generic-abi-unstable)
clean
[libunwind] Tidy-up the testing configuration for libunwind Start testing Apple backdeployment with older libunwinds, and stop explicitly specifying the libunwind testing config, since it is already selected correctly by default. Differential Revision: https://reviews.llvm.org/D126470
2022-05-26 10:19:25 -04:00
generate-cmake -C "${MONOREPO_ROOT}/libcxx/cmake/caches/Generic-abi-unstable.cmake"
[libc++] Add Unstable ABI CI run Reviewed By: ldionne, #libc, Mordante Spies: mgorny, Mordante, libcxx-commits, arichardson Differential Revision: https://reviews.llvm.org/D118725
2022-02-05 14:09:45 +01:00
check-runtimes
;;
[libc++] Use apple-install-libcxx.sh in the Apple/system CI job That script is what we (need to) use to build libc++ for the system configuration, so that's what we should test against. At some point we may be able to fold all of that logic into the CMake build, and when that happens the CI can go back to running CMake directly. As a fly-by fix, stop mentioning x86_64 in the names of the Apple jobs since they are not truly tied to any architecture. Differential Revision: https://reviews.llvm.org/D111865
2021-10-15 00:21:26 -04:00
apple-system)
[libc++] Allow customizing a few paths when running build bots This allows reusing run-buildbot for downstream testing as well.
2020-11-05 19:02:32 -05:00
clean
[libc++] Use apple-install-libcxx.sh in the Apple/system CI job That script is what we (need to) use to build libc++ for the system configuration, so that's what we should test against. At some point we may be able to fold all of that logic into the CMake build, and when that happens the CI can go back to running CMake directly. As a fly-by fix, stop mentioning x86_64 in the names of the Apple jobs since they are not truly tied to any architecture. Differential Revision: https://reviews.llvm.org/D111865
2021-10-15 00:21:26 -04:00
arch="$(uname -m)"
[libc++] Refactor the Apple build scripts This patch upstreams some changes we've made internally to how we're building the libc++ dylib on Apple platforms. The goal is still to eventually get rid of `apple-install-libcxx.sh` entirely and have a proper way to mirror what we do internally with just the normal CMake configuration. Differential Revision: https://reviews.llvm.org/D118912
2022-02-03 10:57:49 -05:00
xcrun --sdk macosx \
${MONOREPO_ROOT}/libcxx/utils/ci/apple-install-libcxx.sh \
--llvm-root ${MONOREPO_ROOT} \
--build-dir ${BUILD_DIR} \
--install-dir ${INSTALL_DIR} \
--symbols-dir "${BUILD_DIR}/symbols" \
--architectures "${arch}" \
--version "999.99"
[libc++] Use apple-install-libcxx.sh in the Apple/system CI job That script is what we (need to) use to build libc++ for the system configuration, so that's what we should test against. At some point we may be able to fold all of that logic into the CMake build, and when that happens the CI can go back to running CMake directly. As a fly-by fix, stop mentioning x86_64 in the names of the Apple jobs since they are not truly tied to any architecture. Differential Revision: https://reviews.llvm.org/D111865
2021-10-15 00:21:26 -04:00
# TODO: It would be better to run the tests against the fake-installed version of libc++ instead
[libc++] Take more knobs into account when generating ABI lists This change will make it possible to track exported symbols in more configurations, notably the Apple system one, where we disable incomplete features and the debug mode. Also, as a fly-by fix, shorten the name for whether new is in libc++ or not. Differential Revision: https://reviews.llvm.org/D119764
2022-02-14 14:39:17 -05:00
xcrun --sdk macosx ninja -vC "${BUILD_DIR}/${arch}" check-cxx check-cxxabi check-cxx-abilist
[libc++][ci] Add a configuration testing Apple's system library build Differential Revision: https://reviews.llvm.org/D88650
2020-10-01 08:55:40 -04:00
;;
[libc++] Allow enabling assertions when back-deploying 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
2022-08-04 15:25:48 -04:00
apple-system-backdeployment-assertions-*)
clean
if [[ "${OSX_ROOTS}" == "" ]]; then
echo "--- Downloading previous macOS dylibs"
PREVIOUS_DYLIBS_URL="https://dl.dropboxusercontent.com/s/gmcfxwgl9f9n6pu/libcxx-roots.tar.gz"
OSX_ROOTS="${BUILD_DIR}/macos-roots"
mkdir -p "${OSX_ROOTS}"
curl "${PREVIOUS_DYLIBS_URL}" | tar -xz --strip-components=1 -C "${OSX_ROOTS}"
fi
DEPLOYMENT_TARGET="${BUILDER#apple-system-backdeployment-assertions-}"
# TODO: On Apple platforms, we never produce libc++abi.1.dylib or libunwind.1.dylib,
# only libc++abi.dylib and libunwind.dylib. Fix that in the build so that the
# tests stop searching for @rpath/libc++abi.1.dylib and @rpath/libunwind.1.dylib.
cp "${OSX_ROOTS}/macOS/libc++abi/${DEPLOYMENT_TARGET}/libc++abi.dylib" \
"${OSX_ROOTS}/macOS/libc++abi/${DEPLOYMENT_TARGET}/libc++abi.1.dylib"
cp "${OSX_ROOTS}/macOS/libunwind/${DEPLOYMENT_TARGET}/libunwind.dylib" \
"${OSX_ROOTS}/macOS/libunwind/${DEPLOYMENT_TARGET}/libunwind.1.dylib"
arch="$(uname -m)"
PARAMS="target_triple=${arch}-apple-macosx${DEPLOYMENT_TARGET}"
PARAMS+=";cxx_runtime_root=${OSX_ROOTS}/macOS/libc++/${DEPLOYMENT_TARGET}"
PARAMS+=";abi_runtime_root=${OSX_ROOTS}/macOS/libc++abi/${DEPLOYMENT_TARGET}"
PARAMS+=";unwind_runtime_root=${OSX_ROOTS}/macOS/libunwind/${DEPLOYMENT_TARGET}"
PARAMS+=";use_system_cxx_lib=True"
PARAMS+=";enable_assertions=True"
# TODO: Enable experimental features during back-deployment -- right now some of the availability
# annotations are incorrect, leading to test failures that could be avoided.
PARAMS+=";enable_experimental=False"
generate-cmake -C "${MONOREPO_ROOT}/libcxx/cmake/caches/Apple.cmake" \
-DLIBCXX_TEST_CONFIG="apple-libc++-backdeployment.cfg.in" \
-DLIBCXXABI_TEST_CONFIG="apple-libc++abi-backdeployment.cfg.in" \
-DLIBUNWIND_TEST_CONFIG="apple-libunwind-backdeployment.cfg.in" \
-DLIBCXX_TEST_PARAMS="${PARAMS}" \
-DLIBCXXABI_TEST_PARAMS="${PARAMS}" \
-DLIBUNWIND_TEST_PARAMS="${PARAMS}"
check-runtimes
;;
[libc++] Use apple-install-libcxx.sh in the Apple/system CI job That script is what we (need to) use to build libc++ for the system configuration, so that's what we should test against. At some point we may be able to fold all of that logic into the CMake build, and when that happens the CI can go back to running CMake directly. As a fly-by fix, stop mentioning x86_64 in the names of the Apple jobs since they are not truly tied to any architecture. Differential Revision: https://reviews.llvm.org/D111865
2021-10-15 00:21:26 -04:00
apple-system-backdeployment-*)
[libc++] Allow customizing a few paths when running build bots This allows reusing run-buildbot for downstream testing as well.
2020-11-05 19:02:32 -05:00
clean
if [[ "${OSX_ROOTS}" == "" ]]; then
echo "--- Downloading previous macOS dylibs"
[libc++] Update URL to old libc++ dylibs
2022-03-15 16:18:45 -04:00
PREVIOUS_DYLIBS_URL="https://dl.dropboxusercontent.com/s/gmcfxwgl9f9n6pu/libcxx-roots.tar.gz"
[libc++] Allow customizing a few paths when running build bots This allows reusing run-buildbot for downstream testing as well.
2020-11-05 19:02:32 -05:00
OSX_ROOTS="${BUILD_DIR}/macos-roots"
mkdir -p "${OSX_ROOTS}"
curl "${PREVIOUS_DYLIBS_URL}" | tar -xz --strip-components=1 -C "${OSX_ROOTS}"
fi
[libc++] Use apple-install-libcxx.sh in the Apple/system CI job That script is what we (need to) use to build libc++ for the system configuration, so that's what we should test against. At some point we may be able to fold all of that logic into the CMake build, and when that happens the CI can go back to running CMake directly. As a fly-by fix, stop mentioning x86_64 in the names of the Apple jobs since they are not truly tied to any architecture. Differential Revision: https://reviews.llvm.org/D111865
2021-10-15 00:21:26 -04:00
DEPLOYMENT_TARGET="${BUILDER#apple-system-backdeployment-}"
[libc++/abi] Allow running back-deployment testing against libc++abi Before this patch, we could only link against the back-deployment libc++abi dylib. This patch allows linking against the just-built libc++abi, but running against the back-deployment one -- just like we do for libc++. Also, add XFAIL markup to flag expected errors. Differential Revision: https://reviews.llvm.org/D91069
2020-07-08 16:38:54 -04:00
[libunwind] Tidy-up the testing configuration for libunwind Start testing Apple backdeployment with older libunwinds, and stop explicitly specifying the libunwind testing config, since it is already selected correctly by default. Differential Revision: https://reviews.llvm.org/D126470
2022-05-26 10:19:25 -04:00
# TODO: On Apple platforms, we never produce libc++abi.1.dylib or libunwind.1.dylib,
# only libc++abi.dylib and libunwind.dylib. Fix that in the build so that the
# tests stop searching for @rpath/libc++abi.1.dylib and @rpath/libunwind.1.dylib.
[libc++/abi] Allow running back-deployment testing against libc++abi Before this patch, we could only link against the back-deployment libc++abi dylib. This patch allows linking against the just-built libc++abi, but running against the back-deployment one -- just like we do for libc++. Also, add XFAIL markup to flag expected errors. Differential Revision: https://reviews.llvm.org/D91069
2020-07-08 16:38:54 -04:00
cp "${OSX_ROOTS}/macOS/libc++abi/${DEPLOYMENT_TARGET}/libc++abi.dylib" \
"${OSX_ROOTS}/macOS/libc++abi/${DEPLOYMENT_TARGET}/libc++abi.1.dylib"
[libunwind] Tidy-up the testing configuration for libunwind Start testing Apple backdeployment with older libunwinds, and stop explicitly specifying the libunwind testing config, since it is already selected correctly by default. Differential Revision: https://reviews.llvm.org/D126470
2022-05-26 10:19:25 -04:00
cp "${OSX_ROOTS}/macOS/libunwind/${DEPLOYMENT_TARGET}/libunwind.dylib" \
"${OSX_ROOTS}/macOS/libunwind/${DEPLOYMENT_TARGET}/libunwind.1.dylib"
[libc++/abi] Allow running back-deployment testing against libc++abi Before this patch, we could only link against the back-deployment libc++abi dylib. This patch allows linking against the just-built libc++abi, but running against the back-deployment one -- just like we do for libc++. Also, add XFAIL markup to flag expected errors. Differential Revision: https://reviews.llvm.org/D91069
2020-07-08 16:38:54 -04:00
[libc++] Use apple-install-libcxx.sh in the Apple/system CI job That script is what we (need to) use to build libc++ for the system configuration, so that's what we should test against. At some point we may be able to fold all of that logic into the CMake build, and when that happens the CI can go back to running CMake directly. As a fly-by fix, stop mentioning x86_64 in the names of the Apple jobs since they are not truly tied to any architecture. Differential Revision: https://reviews.llvm.org/D111865
2021-10-15 00:21:26 -04:00
arch="$(uname -m)"
PARAMS="target_triple=${arch}-apple-macosx${DEPLOYMENT_TARGET}"
[libc++] Allow customizing a few paths when running build bots This allows reusing run-buildbot for downstream testing as well.
2020-11-05 19:02:32 -05:00
PARAMS+=";cxx_runtime_root=${OSX_ROOTS}/macOS/libc++/${DEPLOYMENT_TARGET}"
[libc++/abi] Allow running back-deployment testing against libc++abi Before this patch, we could only link against the back-deployment libc++abi dylib. This patch allows linking against the just-built libc++abi, but running against the back-deployment one -- just like we do for libc++. Also, add XFAIL markup to flag expected errors. Differential Revision: https://reviews.llvm.org/D91069
2020-07-08 16:38:54 -04:00
PARAMS+=";abi_runtime_root=${OSX_ROOTS}/macOS/libc++abi/${DEPLOYMENT_TARGET}"
[libc++abi] Add a from-scratch testing config for Apple backdeployment We added one for libc++ recently, and this patch adds one for libc++abi. Also, as a fly-by fix, include older libunwind dylibs in the testing of libc++ and libc++abi, which fixes some issues related to running back-deployment tests on newer systems. Differential Revision: https://reviews.llvm.org/D119466
2022-02-10 14:03:05 -05:00
PARAMS+=";unwind_runtime_root=${OSX_ROOTS}/macOS/libunwind/${DEPLOYMENT_TARGET}"
[libc++] Allow customizing a few paths when running build bots This allows reusing run-buildbot for downstream testing as well.
2020-11-05 19:02:32 -05:00
PARAMS+=";use_system_cxx_lib=True"
[libc++] Treat incomplete features just like other experimental features 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
2022-06-30 11:57:52 -04:00
# TODO: Enable experimental features during back-deployment -- right now some of the availability
# annotations are incorrect, leading to test failures that could be avoided.
PARAMS+=";enable_experimental=False"
[libc++] Allow customizing a few paths when running build bots This allows reusing run-buildbot for downstream testing as well.
2020-11-05 19:02:32 -05:00
generate-cmake -C "${MONOREPO_ROOT}/libcxx/cmake/caches/Apple.cmake" \
[libc++] Add a Lit configuration for running back-deployment tests This testing configuration links tests against one libc++ shared library, but runs them against another libc++ shared library. This makes sure that we can build applications against the libc++ provided in a recent SDK and back-deploy them to platforms containing older libc++ dylibs. It also switches the Apple CI script to using that new configuration instead of the legacy one. Differential Revision: https://reviews.llvm.org/D119195
2022-02-07 17:25:41 -05:00
-DLIBCXX_TEST_CONFIG="apple-libc++-backdeployment.cfg.in" \
[libc++abi] Add a from-scratch testing config for Apple backdeployment We added one for libc++ recently, and this patch adds one for libc++abi. Also, as a fly-by fix, include older libunwind dylibs in the testing of libc++ and libc++abi, which fixes some issues related to running back-deployment tests on newer systems. Differential Revision: https://reviews.llvm.org/D119466
2022-02-10 14:03:05 -05:00
-DLIBCXXABI_TEST_CONFIG="apple-libc++abi-backdeployment.cfg.in" \
[libunwind] Tidy-up the testing configuration for libunwind Start testing Apple backdeployment with older libunwinds, and stop explicitly specifying the libunwind testing config, since it is already selected correctly by default. Differential Revision: https://reviews.llvm.org/D126470
2022-05-26 10:19:25 -04:00
-DLIBUNWIND_TEST_CONFIG="apple-libunwind-backdeployment.cfg.in" \
[libc++] Allow customizing a few paths when running build bots This allows reusing run-buildbot for downstream testing as well.
2020-11-05 19:02:32 -05:00
-DLIBCXX_TEST_PARAMS="${PARAMS}" \
[libunwind] Tidy-up the testing configuration for libunwind Start testing Apple backdeployment with older libunwinds, and stop explicitly specifying the libunwind testing config, since it is already selected correctly by default. Differential Revision: https://reviews.llvm.org/D126470
2022-05-26 10:19:25 -04:00
-DLIBCXXABI_TEST_PARAMS="${PARAMS}" \
-DLIBUNWIND_TEST_PARAMS="${PARAMS}"
[libc++] Allow customizing a few paths when running build bots This allows reusing run-buildbot for downstream testing as well.
2020-11-05 19:02:32 -05:00
[runtimes][ci] Run the tests for libunwind in the CI We should arguably have always been doing that. The state of libunwind is quite sad, so this commit adds several XFAILs to make the CI pass. We need to investigate why so many tests are not passing in some configurations, but I'll defer that to folks who actually work on libunwind for lack of bandwidth. Differential Revision: https://reviews.llvm.org/D110872
2021-09-30 15:11:48 -04:00
check-runtimes
[libc++] Add a Buildkite job that tests back-deployment on Apple The current way we test this is pretty cheap, i.e. we download previously released macOS dylibs and run against that. Ideally, we would require a full host running the appropriate version of macOS, and we'd execute the tests using SSH on that host. But since we don't have such hosts available easily for now, this is better than nothing. At the same time, also fix some tests that were failing when back deploying. Differential Revision: https://reviews.llvm.org/D90869
2020-11-05 10:47:06 -05:00
;;
[libc++] Refactor the run-buildbot script to make it more modular, and run the benchmarks As a fly-by fix, unbreak the benchmarks on Apple platforms. Differential Revision: https://reviews.llvm.org/D90043
2020-10-23 10:02:14 -04:00
benchmarks)
[libc++] Allow customizing a few paths when running build bots This allows reusing run-buildbot for downstream testing as well.
2020-11-05 19:02:32 -05:00
clean
[libunwind] Tidy-up the testing configuration for libunwind Start testing Apple backdeployment with older libunwinds, and stop explicitly specifying the libunwind testing config, since it is already selected correctly by default. Differential Revision: https://reviews.llvm.org/D126470
2022-05-26 10:19:25 -04:00
generate-cmake
[libc++] Refactor the run-buildbot script to make it more modular, and run the benchmarks As a fly-by fix, unbreak the benchmarks on Apple platforms. Differential Revision: https://reviews.llvm.org/D90043
2020-10-23 10:02:14 -04:00
check-cxx-benchmarks
[libc++][ci] Add a configuration testing Apple's system library build Differential Revision: https://reviews.llvm.org/D88650
2020-10-01 08:55:40 -04:00
;;
[libc++] Add a CI job to build the documentation At the same time, fix an issue that broke the documentation since 2eadbc86142b.
2020-11-05 14:34:29 -05:00
documentation)
[libc++] Allow customizing a few paths when running build bots This allows reusing run-buildbot for downstream testing as well.
2020-11-05 19:02:32 -05:00
clean
generate-cmake -DLLVM_ENABLE_SPHINX=ON
echo "+++ Generating documentation"
[libc++] Run ninja with --verbose This makes it easier to see what exact build commands are used. Differential Revision: https://reviews.llvm.org/D98992
2021-03-19 16:26:15 -07:00
${NINJA} -vC "${BUILD_DIR}" docs-libcxx-html
[libc++] Add a CI job to build the documentation At the same time, fix an issue that broke the documentation since 2eadbc86142b.
2020-11-05 14:34:29 -05:00
;;
[runtimes] Rename CI job from "Runtimes build" to "Bootstrapping build"
2021-10-20 17:43:55 -04:00
bootstrapping-build)
[libc++] Add a CI job to test the Runtimes build Differential Revision: https://reviews.llvm.org/D97888
2021-03-16 11:57:42 -07:00
clean
echo "--- Generating CMake"
[libc++] Use Xcode's CMake if it's present This resolves issues when the CMake in use on the host is too old to configure libc++ properly, but Xcode has a sufficiently recent version. It is technically possible for the reverse issue to happen, where the Xcode version would be too old and the user-installed version would be better, however in the context of our build bots, we use AppleClang on Apple platforms, and the CMake shipped with Xcode should work with the AppleClang shipped alongside that Xcode. Differential Revision: https://reviews.llvm.org/D102083
2021-05-07 13:14:57 -04:00
${CMAKE} \
-S "${MONOREPO_ROOT}/llvm" \
[libc++] Add a CI job to test the Runtimes build Differential Revision: https://reviews.llvm.org/D97888
2021-03-16 11:57:42 -07:00
-B "${BUILD_DIR}" \
[libc++] Use Xcode's CMake if it's present This resolves issues when the CMake in use on the host is too old to configure libc++ properly, but Xcode has a sufficiently recent version. It is technically possible for the reverse issue to happen, where the Xcode version would be too old and the user-installed version would be better, however in the context of our build bots, we use AppleClang on Apple platforms, and the CMake shipped with Xcode should work with the AppleClang shipped alongside that Xcode. Differential Revision: https://reviews.llvm.org/D102083
2021-05-07 13:14:57 -04:00
-GNinja -DCMAKE_MAKE_PROGRAM="${NINJA}" \
Revert "[libc++][ci] Disable generating debug information." The bug this patch works around prevents D70631 to land. Remove the work-around since it's no longer needed.
2021-12-08 17:58:51 +01:00
-DCMAKE_BUILD_TYPE=RelWithDebInfo \
[libc++] Add a CI job to test the Runtimes build Differential Revision: https://reviews.llvm.org/D97888
2021-03-16 11:57:42 -07:00
-DCMAKE_INSTALL_PREFIX="${INSTALL_DIR}" \
-DLLVM_ENABLE_PROJECTS="clang" \
[libunwind] Add libunwind to the bootstrapping build CI Differential Revision: https://reviews.llvm.org/D122006
2022-03-18 10:03:01 -04:00
-DLLVM_ENABLE_RUNTIMES="libcxx;libcxxabi;libunwind" \
[libc++] Allow running the bootstrapping CI build on Darwin Instead of hard-coding the target for our CI nodes, use the default compiler triple. Also, allow building compiler-rt for the single specified triple in case we're running on Darwin (otherwise, the bootstrapping build complains). Differential Revision: https://reviews.llvm.org/D113683
2021-11-11 11:55:20 -05:00
-DLLVM_RUNTIME_TARGETS="$(c++ --print-target-triple)" \
[libcxx] CI: only build native target for bootstrapping-build Signed-off-by: Matheus Izvekov <mizvekov@gmail.com> Reviewed By: #libc, ldionne Differential Revision: https://reviews.llvm.org/D113950
2021-11-16 00:32:48 +01:00
-DLLVM_TARGETS_TO_BUILD="host" \
[libc++] Allow running the bootstrapping CI build on Darwin Instead of hard-coding the target for our CI nodes, use the default compiler triple. Also, allow building compiler-rt for the single specified triple in case we're running on Darwin (otherwise, the bootstrapping build complains). Differential Revision: https://reviews.llvm.org/D113683
2021-11-11 11:55:20 -05:00
-DRUNTIMES_BUILD_ALLOW_DARWIN=ON \
[libunwind] Tidy-up the testing configuration for libunwind Start testing Apple backdeployment with older libunwinds, and stop explicitly specifying the libunwind testing config, since it is already selected correctly by default. Differential Revision: https://reviews.llvm.org/D126470
2022-05-26 10:19:25 -04:00
-DLLVM_ENABLE_ASSERTIONS=ON
[libc++] Add a CI job to test the Runtimes build Differential Revision: https://reviews.llvm.org/D97888
2021-03-16 11:57:42 -07:00
echo "+++ Running the libc++ and libc++abi tests"
${NINJA} -C "${BUILD_DIR}" check-runtimes
echo "--- Installing libc++ and libc++abi to a fake location"
[libc++][docs] Overhaul the documentation for building and using libc++ This patch overhauls the documentation around building libc++ for vendors, and using libc++ for end-users. It also: - Removes mention of the standalone build, which we've been trying to get rid of for a long time. - Removes mention of using a local ABI installation, which we don't do and is documented as "not recommended". - Removes mention of the separate libc++filesystem.a library, which isn't relevant anymore since filesystem support is in the main library. - Adds mention of the GDB pretty printers and how to use them.
2021-07-06 10:39:01 -04:00
${NINJA} -C "${BUILD_DIR}" install-runtimes
[libc++] Add a CI job to test the Runtimes build Differential Revision: https://reviews.llvm.org/D97888
2021-03-16 11:57:42 -07:00
;;
[libcxx] Move Linaro AArch64 buildbots to buildkite Reviewed By: #libc, ldionne Differential Revision: https://reviews.llvm.org/D96267
2021-02-08 10:43:21 +00:00
aarch64)
clean
[libunwind] Tidy-up the testing configuration for libunwind Start testing Apple backdeployment with older libunwinds, and stop explicitly specifying the libunwind testing config, since it is already selected correctly by default. Differential Revision: https://reviews.llvm.org/D126470
2022-05-26 10:19:25 -04:00
generate-cmake -C "${MONOREPO_ROOT}/libcxx/cmake/caches/AArch64.cmake"
[runtimes][ci] Run the tests for libunwind in the CI We should arguably have always been doing that. The state of libunwind is quite sad, so this commit adds several XFAILs to make the CI pass. We need to investigate why so many tests are not passing in some configurations, but I'll defer that to folks who actually work on libunwind for lack of bandwidth. Differential Revision: https://reviews.llvm.org/D110872
2021-09-30 15:11:48 -04:00
check-runtimes
[libcxx] Move Linaro AArch64 buildbots to buildkite Reviewed By: #libc, ldionne Differential Revision: https://reviews.llvm.org/D96267
2021-02-08 10:43:21 +00:00
;;
aarch64-noexceptions)
clean
generate-cmake -C "${MONOREPO_ROOT}/libcxx/cmake/caches/AArch64.cmake" \
[libc++] NFC: Reindent the run-buildbot script
2021-07-15 13:29:47 -04:00
-DLIBCXX_ENABLE_EXCEPTIONS=OFF \
[libunwind] Tidy-up the testing configuration for libunwind Start testing Apple backdeployment with older libunwinds, and stop explicitly specifying the libunwind testing config, since it is already selected correctly by default. Differential Revision: https://reviews.llvm.org/D126470
2022-05-26 10:19:25 -04:00
-DLIBCXXABI_ENABLE_EXCEPTIONS=OFF
[runtimes][ci] Run the tests for libunwind in the CI We should arguably have always been doing that. The state of libunwind is quite sad, so this commit adds several XFAILs to make the CI pass. We need to investigate why so many tests are not passing in some configurations, but I'll defer that to folks who actually work on libunwind for lack of bandwidth. Differential Revision: https://reviews.llvm.org/D110872
2021-09-30 15:11:48 -04:00
check-runtimes
[libcxx] Move Linaro AArch64 buildbots to buildkite Reviewed By: #libc, ldionne Differential Revision: https://reviews.llvm.org/D96267
2021-02-08 10:43:21 +00:00
;;
[libcxx] Move Linaro 32 bit armv bots to buildkite Instead of setting mcpu like the previous bots, set the target triple. Each config builds either Arm only or Thumb only code. This gives us some coverage of thumb specific issues. The new agents on Linaro's side are running on v8 hardware so will report arch "armv8l" just like the v8 bots. (and buildkite can choose any of them for v7/v8 jobs) Reviewed By: #libc, curdeius, Mordante Differential Revision: https://reviews.llvm.org/D98019
2021-03-02 15:07:19 +00:00
# Aka Armv8 32 bit
armv8)
clean
[libunwind] Tidy-up the testing configuration for libunwind Start testing Apple backdeployment with older libunwinds, and stop explicitly specifying the libunwind testing config, since it is already selected correctly by default. Differential Revision: https://reviews.llvm.org/D126470
2022-05-26 10:19:25 -04:00
generate-cmake -C "${MONOREPO_ROOT}/libcxx/cmake/caches/Armv8Arm.cmake"
[runtimes][ci] Run the tests for libunwind in the CI We should arguably have always been doing that. The state of libunwind is quite sad, so this commit adds several XFAILs to make the CI pass. We need to investigate why so many tests are not passing in some configurations, but I'll defer that to folks who actually work on libunwind for lack of bandwidth. Differential Revision: https://reviews.llvm.org/D110872
2021-09-30 15:11:48 -04:00
check-runtimes
[libcxx] Move Linaro 32 bit armv bots to buildkite Instead of setting mcpu like the previous bots, set the target triple. Each config builds either Arm only or Thumb only code. This gives us some coverage of thumb specific issues. The new agents on Linaro's side are running on v8 hardware so will report arch "armv8l" just like the v8 bots. (and buildkite can choose any of them for v7/v8 jobs) Reviewed By: #libc, curdeius, Mordante Differential Revision: https://reviews.llvm.org/D98019
2021-03-02 15:07:19 +00:00
;;
armv8-noexceptions)
clean
[libunwind] Tidy-up the testing configuration for libunwind Start testing Apple backdeployment with older libunwinds, and stop explicitly specifying the libunwind testing config, since it is already selected correctly by default. Differential Revision: https://reviews.llvm.org/D126470
2022-05-26 10:19:25 -04:00
generate-cmake -C "${MONOREPO_ROOT}/libcxx/cmake/caches/Armv8Thumb-noexceptions.cmake"
[runtimes][ci] Run the tests for libunwind in the CI We should arguably have always been doing that. The state of libunwind is quite sad, so this commit adds several XFAILs to make the CI pass. We need to investigate why so many tests are not passing in some configurations, but I'll defer that to folks who actually work on libunwind for lack of bandwidth. Differential Revision: https://reviews.llvm.org/D110872
2021-09-30 15:11:48 -04:00
check-runtimes
[libcxx] Move Linaro 32 bit armv bots to buildkite Instead of setting mcpu like the previous bots, set the target triple. Each config builds either Arm only or Thumb only code. This gives us some coverage of thumb specific issues. The new agents on Linaro's side are running on v8 hardware so will report arch "armv8l" just like the v8 bots. (and buildkite can choose any of them for v7/v8 jobs) Reviewed By: #libc, curdeius, Mordante Differential Revision: https://reviews.llvm.org/D98019
2021-03-02 15:07:19 +00:00
;;
# Armv7 32 bit. One building Arm only one Thumb only code.
armv7)
clean
[libunwind] Tidy-up the testing configuration for libunwind Start testing Apple backdeployment with older libunwinds, and stop explicitly specifying the libunwind testing config, since it is already selected correctly by default. Differential Revision: https://reviews.llvm.org/D126470
2022-05-26 10:19:25 -04:00
generate-cmake -C "${MONOREPO_ROOT}/libcxx/cmake/caches/Armv7Arm.cmake"
[runtimes][ci] Run the tests for libunwind in the CI We should arguably have always been doing that. The state of libunwind is quite sad, so this commit adds several XFAILs to make the CI pass. We need to investigate why so many tests are not passing in some configurations, but I'll defer that to folks who actually work on libunwind for lack of bandwidth. Differential Revision: https://reviews.llvm.org/D110872
2021-09-30 15:11:48 -04:00
check-runtimes
[libcxx] Move Linaro 32 bit armv bots to buildkite Instead of setting mcpu like the previous bots, set the target triple. Each config builds either Arm only or Thumb only code. This gives us some coverage of thumb specific issues. The new agents on Linaro's side are running on v8 hardware so will report arch "armv8l" just like the v8 bots. (and buildkite can choose any of them for v7/v8 jobs) Reviewed By: #libc, curdeius, Mordante Differential Revision: https://reviews.llvm.org/D98019
2021-03-02 15:07:19 +00:00
;;
armv7-noexceptions)
clean
[libunwind] Tidy-up the testing configuration for libunwind Start testing Apple backdeployment with older libunwinds, and stop explicitly specifying the libunwind testing config, since it is already selected correctly by default. Differential Revision: https://reviews.llvm.org/D126470
2022-05-26 10:19:25 -04:00
generate-cmake -C "${MONOREPO_ROOT}/libcxx/cmake/caches/Armv7Thumb-noexceptions.cmake"
[runtimes][ci] Run the tests for libunwind in the CI We should arguably have always been doing that. The state of libunwind is quite sad, so this commit adds several XFAILs to make the CI pass. We need to investigate why so many tests are not passing in some configurations, but I'll defer that to folks who actually work on libunwind for lack of bandwidth. Differential Revision: https://reviews.llvm.org/D110872
2021-09-30 15:11:48 -04:00
check-runtimes
[libcxx] Move Linaro 32 bit armv bots to buildkite Instead of setting mcpu like the previous bots, set the target triple. Each config builds either Arm only or Thumb only code. This gives us some coverage of thumb specific issues. The new agents on Linaro's side are running on v8 hardware so will report arch "armv8l" just like the v8 bots. (and buildkite can choose any of them for v7/v8 jobs) Reviewed By: #libc, curdeius, Mordante Differential Revision: https://reviews.llvm.org/D98019
2021-03-02 15:07:19 +00:00
;;
[libcxx] [ci] Add CI configurations for MinGW Mention support for MinGW in the docs. Rename the existing windows CI jobs to Clang-cl, as both Clang-cl and MinGW are equally much "Windows", just different toolchain environments. Add an XFAIL for a recently added test that fails in the MinGW DLL configuration (with an explanation of what's causing the failure). Differential Revision: https://reviews.llvm.org/D112215
2021-10-01 23:08:57 +03:00
clang-cl-dll)
[libcxx] [ci] Add a Windows CI buildkite configuration Differential Revision: https://reviews.llvm.org/D99093
2021-03-17 12:10:42 +02:00
clean
# TODO: Currently, building with the experimental library breaks running
# tests (the test linking look for the c++experimental library with the
# wrong name, and the statically linked c++experimental can't be linked
# correctly when libc++ visibility attributes indicate dllimport linkage
# anyway), thus just disable the experimental library. Remove this
# setting when cmake and the test driver does the right thing automatically.
[libc++] Re-apply "Always build c++experimental.a"" This re-applies bb939931a1ad, which had been reverted by 09cebfb978de because it broke Chromium. The issues seen by Chromium should be addressed by 1d0f79558ca4. Differential Revision: https://reviews.llvm.org/D128927
2022-07-19 10:44:06 -04:00
generate-cmake-libcxx-win -DLIBCXX_TEST_PARAMS="enable_experimental=False"
[libcxx] [ci] Add a Windows CI configuration for a statically linked libc++ On Windows, static vs DLL linking affects details in quite a few cases, so it's good to have coverage for both cases. Testing with static linking also increases coverage for a number of cases and individual checks that have had to be waived for the DLL case, and allows testing libc++experimental, increasing the number of test cases actually executed by 180 (176 new tests from libc++experimental and 4 ones that are XFAIL windows-dll). Also drop the "generic-" prefix from these configuration names, as they're perhaps not what the "generic" prefix intended originally in the other generic-posix configurations. Differential Revision: https://reviews.llvm.org/D101565
2021-04-06 00:17:30 +03:00
echo "+++ Running the libc++ tests"
${NINJA} -vC "${BUILD_DIR}" check-cxx
;;
[libcxx] [ci] Add CI configurations for MinGW Mention support for MinGW in the docs. Rename the existing windows CI jobs to Clang-cl, as both Clang-cl and MinGW are equally much "Windows", just different toolchain environments. Add an XFAIL for a recently added test that fails in the MinGW DLL configuration (with an explanation of what's causing the failure). Differential Revision: https://reviews.llvm.org/D112215
2021-10-01 23:08:57 +03:00
clang-cl-static)
[libcxx] [ci] Add a Windows CI configuration for a statically linked libc++ On Windows, static vs DLL linking affects details in quite a few cases, so it's good to have coverage for both cases. Testing with static linking also increases coverage for a number of cases and individual checks that have had to be waived for the DLL case, and allows testing libc++experimental, increasing the number of test cases actually executed by 180 (176 new tests from libc++experimental and 4 ones that are XFAIL windows-dll). Also drop the "generic-" prefix from these configuration names, as they're perhaps not what the "generic" prefix intended originally in the other generic-posix configurations. Differential Revision: https://reviews.llvm.org/D101565
2021-04-06 00:17:30 +03:00
clean
[libc++] Switch to the new testing configurations by default We've been meaning to remove support for the legacy testing configuration for a long time. This patch switches the default from the legacy config to the appropriate new-style configuration based on a few hints. We've been running with the new-style configuration for more than a year in our CI, however it's possible that this will uncover issues with some users that run the tests on platforms that we don't support yet with the new-style configs. Unfortunately, there is no way to know about it other than to land this patch and see whether anything breaks. Differential Revision: https://reviews.llvm.org/D121632
2022-03-14 14:23:38 -04:00
generate-cmake-libcxx-win -DLIBCXX_ENABLE_SHARED=OFF
[libcxx] [ci] Add a Windows CI buildkite configuration Differential Revision: https://reviews.llvm.org/D99093
2021-03-17 12:10:42 +02:00
echo "+++ Running the libc++ tests"
${NINJA} -vC "${BUILD_DIR}" check-cxx
[libcxx] [ci] Add CI configurations for MinGW Mention support for MinGW in the docs. Rename the existing windows CI jobs to Clang-cl, as both Clang-cl and MinGW are equally much "Windows", just different toolchain environments. Add an XFAIL for a recently added test that fails in the MinGW DLL configuration (with an explanation of what's causing the failure). Differential Revision: https://reviews.llvm.org/D112215
2021-10-01 23:08:57 +03:00
;;
[libcxx] Fix using the vcruntime ABI with _HAS_EXCEPTIONS=0 defined _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
2022-08-17 20:57:59 +00:00
clang-cl-no-vcruntime)
clean
# Building libc++ in the same way as in clang-cl-dll above, but running
# tests with -D_HAS_EXCEPTIONS=0, which users might set in certain
# translation units while using libc++, even if libc++ is built with
# exceptions enabled.
generate-cmake-libcxx-win -DLIBCXX_TEST_PARAMS="enable_experimental=False" \
-DLIBCXX_TEST_CONFIG="llvm-libc++-shared-no-vcruntime-clangcl.cfg.in"
echo "+++ Running the libc++ tests"
${NINJA} -vC "${BUILD_DIR}" check-cxx
;;
[libcxx] [ci] Add CI configurations for MinGW Mention support for MinGW in the docs. Rename the existing windows CI jobs to Clang-cl, as both Clang-cl and MinGW are equally much "Windows", just different toolchain environments. Add an XFAIL for a recently added test that fails in the MinGW DLL configuration (with an explanation of what's causing the failure). Differential Revision: https://reviews.llvm.org/D112215
2021-10-01 23:08:57 +03:00
mingw-dll)
clean
# Explicitly specify the compiler with a triple prefix. The CI
# environment has got two installations of Clang; the default one
# defaults to MSVC mode, while there's an installation of llvm-mingw
# further back in PATH. By calling the compiler with an explicit
# triple prefix, we use the one that is bundled with a mingw sysroot.
generate-cmake \
-DCMAKE_C_COMPILER=x86_64-w64-mingw32-clang \
-DCMAKE_CXX_COMPILER=x86_64-w64-mingw32-clang++ \
-C "${MONOREPO_ROOT}/libcxx/cmake/caches/MinGW.cmake"
echo "+++ Running the libc++ tests"
${NINJA} -vC "${BUILD_DIR}" check-cxx
;;
mingw-static)
clean
generate-cmake \
-DCMAKE_C_COMPILER=x86_64-w64-mingw32-clang \
-DCMAKE_CXX_COMPILER=x86_64-w64-mingw32-clang++ \
-C "${MONOREPO_ROOT}/libcxx/cmake/caches/MinGW.cmake" \
-DLIBCXX_ENABLE_SHARED=OFF \
-DLIBUNWIND_ENABLE_SHARED=OFF
echo "+++ Running the libc++ tests"
${NINJA} -vC "${BUILD_DIR}" check-cxx
[libcxx] [ci] Add a i386 Windows configuration to CI Adding a mingw based config is easy in the current CI environment (where we can just choose the different target by calling `i686-w64-mingw32-clang`), while adding a clang-cl based config would require setting up different environment variables pointing to the i386 library directory. Just adding one config (DLL) instead of exhaustively testing both (DLL and static) as very few tests would differ in practice, to keep the CI load reasonable. Differential Revision: https://reviews.llvm.org/D124991
2022-05-04 11:05:44 +03:00
;;
mingw-dll-i686)
clean
generate-cmake \
-DCMAKE_C_COMPILER=i686-w64-mingw32-clang \
-DCMAKE_CXX_COMPILER=i686-w64-mingw32-clang++ \
-C "${MONOREPO_ROOT}/libcxx/cmake/caches/MinGW.cmake"
echo "+++ Running the libc++ tests"
${NINJA} -vC "${BUILD_DIR}" check-cxx
[libcxx] [ci] Add a Windows CI buildkite configuration Differential Revision: https://reviews.llvm.org/D99093
2021-03-17 12:10:42 +02:00
;;
[libc++][AIX] Add scripts and config for building with the libcxx CI infrastructure This initial change adds the AIX configuration to run-buildbot, an AIX CMake cache file, and appropriate compiler and linker flags for testing AIX to the lit "from scratch" configuration files. Either of the 32-bit or 64-bit configurations can be built by setting `OBJECT_MODE` in the build environment (as is typical for AIX). Reviewed By: ldionne, #libc, #libc_abi Differential Revision: https://reviews.llvm.org/D111244
2021-10-13 11:41:47 -04:00
aix)
clean
[libcxx][CI][AIX] Switch to LLVM_ENABLE_RUNTIMES and to the new `runtimes` top level CMakeLists.txt since the old path is now deprecated. This requires a slight adjustment of the libcxxabi CMake, since there are required macro definitions we previously got via the `llvm/CMakeList.txt` path. Reviewed By: ldionne, #libc, #libc_abi Differential Revision: https://reviews.llvm.org/D113403
2021-11-09 12:44:44 -05:00
generate-cmake -C "${MONOREPO_ROOT}/libcxx/cmake/caches/AIX.cmake" \
[libc++][AIX] Add scripts and config for building with the libcxx CI infrastructure This initial change adds the AIX configuration to run-buildbot, an AIX CMake cache file, and appropriate compiler and linker flags for testing AIX to the lit "from scratch" configuration files. Either of the 32-bit or 64-bit configurations can be built by setting `OBJECT_MODE` in the build environment (as is typical for AIX). Reviewed By: ldionne, #libc, #libc_abi Differential Revision: https://reviews.llvm.org/D111244
2021-10-13 11:41:47 -04:00
-DLIBCXX_TEST_CONFIG="ibm-libc++-shared.cfg.in" \
[libcxx][CI][AIX] Switch to LLVM_ENABLE_RUNTIMES and to the new `runtimes` top level CMakeLists.txt since the old path is now deprecated. This requires a slight adjustment of the libcxxabi CMake, since there are required macro definitions we previously got via the `llvm/CMakeList.txt` path. Reviewed By: ldionne, #libc, #libc_abi Differential Revision: https://reviews.llvm.org/D113403
2021-11-09 12:44:44 -05:00
-DLIBCXXABI_TEST_CONFIG="ibm-libc++abi-shared.cfg.in" \
[libunwind][ci][AIX] Add libunwind to buildbot CI Summary: This patch changes scripts to add libunwind CI on AIX. Test config file ibm-libunwind-shared.cfg.in is introduced for testing on AIX. Reviewed by: ldionne, MaskRay, libunwind, ibc++abi Differential Revision: https://reviews.llvm.org/D126017
2022-06-02 09:03:10 -04:00
-DLIBUNWIND_TEST_CONFIG="ibm-libunwind-shared.cfg.in"
[libcxx][AIX] Enable ABI list checking for XCOFF The existing nm extractors can't dump the loader symbol table information we need to do the ABI checks for XCOFF, so provide an implementation using the system dump utility. We match the symbol name, whether it's defined, it's import/export status, and its storage mapping class. Reviewed By: #libc, ldionne Differential Revision: https://reviews.llvm.org/D124165
2022-06-14 13:15:46 -04:00
check-abi-list
[libunwind][ci][AIX] Add libunwind to buildbot CI Summary: This patch changes scripts to add libunwind CI on AIX. Test config file ibm-libunwind-shared.cfg.in is introduced for testing on AIX. Reviewed by: ldionne, MaskRay, libunwind, ibc++abi Differential Revision: https://reviews.llvm.org/D126017
2022-06-02 09:03:10 -04:00
check-runtimes
[libc++][AIX] Add scripts and config for building with the libcxx CI infrastructure This initial change adds the AIX configuration to run-buildbot, an AIX CMake cache file, and appropriate compiler and linker flags for testing AIX to the lit "from scratch" configuration files. Either of the 32-bit or 64-bit configurations can be built by setting `OBJECT_MODE` in the build environment (as is typical for AIX). Reviewed By: ldionne, #libc, #libc_abi Differential Revision: https://reviews.llvm.org/D111244
2021-10-13 11:41:47 -04:00
;;
[libc++] NFC: Make it easier for vendors to extend the run-buildbot script
2021-05-27 16:51:38 -04:00
#################################################################
# Insert vendor-specific internal configurations below.
#
# This allows vendors to extend this file with their own internal
# configurations without running into merge conflicts with upstream.
#################################################################
#################################################################
[libc++] Initial support for pre-commit CI with Buildkite This commit adds basic files and scripts that are used for the Buildkite pre-commit CI setup. This was tested to mostly work on a fork of llvm-project, however some adjustments will have to be made as we complete the real setup.
2020-09-23 09:20:03 -04:00
*)
echo "${BUILDER} is not a known configuration"
exit 1
;;
esac
Reference in New Issue Copy Permalink