Details
- Reviewers
ldionne - Group Reviewers
Restricted Project - Commits
- rG5bf8de882ae9: [libc++][CI] Upgrades to LLVM 18 as HEAD version.
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
libcxx/utils/ci/buildkite-pipeline.yml | ||
---|---|---|
302 | We still officially support clang-15. The main idea is to make sure we still work with clang-15 so we can be sure backported patches work on clang-15. Once LLVM 17 is released this can be removed. What do you mean with automatically? | |
339 | This will fail until we update to CMake 3.27, which is on my todo list. |
libcxx/utils/ci/buildkite-pipeline.yml | ||
---|---|---|
302 | This doesn't really make sense to me. This would require us to keep 15 until we are branching for LLVM 18, since there will be fixes backported until then. IMO the right thing to make this working properly is to run the CI on the release branch when a libc++ patch is backported. I mean that we use label: "Clang ${LLVM_STABLE_VERSION}-1" (or however you have to write it to make it work) and then just update the version at the top of the file. |
libcxx/utils/ci/buildkite-pipeline.yml | ||
---|---|---|
302 | The idea was to keep 15 until 17 is released to make backporting easier while the 17 branch is stabilized. Once 17 is released the number of backports, hopefully will slow down significantly. That is also the moment when we officially drop 15 support. We hard-code the value for the older releases 16 and 17 too so I did the same here. |
Is there a reason we keep 15 around? Also, could we make these changes automatic like we do for GCC?