_LIBCPP_REMOVE_TRANSITIVE_INCLUDES doesn't do anything anymore in C++23 mode, so it's now just a duplicate of the C++23 configuration.
Also add new steps to the post-release checklist for updating the supported compilers.
Details
- Reviewers
ldionne Mordante var-const huixie90 - Group Reviewers
Restricted Project - Commits
- rGe52ce7f55449: [libc++] Remove old CI configurations and update the supported compiler versions
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Please coordinate with @Mordante. I just approved a patch that removed support for Clang 13. I think this could become only a removal of the generic-no-transitive-includes CI configuration.
Thanks for working on this!
libcxx/docs/index.rst | ||
---|---|---|
107 | I would prefer to only mention releases here. Having Clang 16 may lead to confusion since it's not released yet. | |
libcxx/utils/ci/buildkite-pipeline.yml | ||
259 | This part has already landed. | |
505 | I didn't remove this part, and I would prefer it in a separate commit; which can be this commit. |
libcxx/docs/index.rst | ||
---|---|---|
107 | I was actually always confused by the latest two stable releases. The released versions also only claim support for the last two versions, i.e. libc++14 claims compatibility with clang 12 and 13, but not 14 (see https://releases.llvm.org/14.0.0/projects/libcxx/docs/index.html), which I find very confusing. The new wording makes the situation clear. | |
libcxx/utils/ci/buildkite-pipeline.yml | ||
505 | I'll split it if we want to reword the supported compilers. |
libcxx/docs/index.rst | ||
---|---|---|
107 | I see what you mean. However I think this wording doesn't work. When LLVM 16 will be released and current trunk would refer to LLVM 17. So that means LLVM 16 supports 14, 15, and 17. Still not 16. Maybe then we should list it like suggested. Then we need to make sure we update this just prior to a release. How about adding a pre-release checklist here https://libcxx.llvm.org/Contributing.html? |
I would prefer to only mention releases here. Having Clang 16 may lead to confusion since it's not released yet.
For AppleClang we already have some version 14 support.
I feel having support for the work-in-progress function can be left implicit.