ci: verify both standard libraries as required gates - #20
Merged
Conversation
The requirements say Clang works with either libstdc++ or libc++, but only libstdc++ was covered by a required gate — libc++ sat in the nightly watch, which makes it best effort rather than something the project stands behind. Promote it: build the lower bound Clang against libc++ as well. libc++ is not part of the runner image, but it comes from the distribution's own repository, so no external source enters a required gate. Verifying it at the lower bound is the useful half: a newer libc++ paired with a newer Clang is the easier combination. State the choice in the requirements too, and narrow the explanation in the getting started guide to the libstdc++ headers actually tried (14) rather than implying every newer release was ruled out.
The requirements promise either standard library across Clang 20-22, but the libc++ gate only covered 20. The justification for stopping there — that a newer libc++ with a newer Clang is the easier pairing — was a guess, and it does not cover what actually breaks at the upper end: libc++ header changes and newly added warnings. -Werror is public here, so those reach consumers rather than staying in our CI. Match the gate to the claim and verify both ends.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
The requirements state that Clang works with either libstdc++ or libc++, but only libstdc++ was actually covered by a required gate. libc++ sat in the nightly watch, which makes it best effort — not something the project stands behind. A user picking libc++ had no guarantee it would keep building.
That gap was easy to miss because it reads fine either way: "the required gates build against the default standard library, the nightly watch covers the other one" sounds balanced, but only one of the two is a promise.
What changed
Ubuntu Clang 20 libc++andUbuntu Clang 22 libc++are now required gates (Debug and Release each). Both ends of the declared Clang range are built against libc++ in addition to the default standard library.nightly.yml, since it is no longer best effort.Covering both ends rather than just the lower bound is deliberate. Stopping at the lower bound would have left the upper end of the declared range unverified against libc++ header changes and newly added warnings — and
-WerrorisPUBLIChere, so those reach consumers rather than staying in this project's CI.libc++ is not part of the runner image, so this adds an
apt-get install. It comes from the distribution's own repository, which is what the required gates already rely on for everything else — no external source enters the required path.Check count
Build checks go from 16 to 20 — the same total as before this series of changes, with the contents swapped: the four macOS Homebrew GCC jobs that were never part of the declared support are gone, and four libc++ jobs that the requirements do promise have taken their place.