Include <compare> in a generated semantic type - #191
Conversation
A generated semantic type defaults `operator<=>`, which answers with one of the ordering types in <compare>. The header never included it. libstdc++ happens to have declared those types by the time the generated header is read and libc++ does not, so the type compiled under GCC and was refused by Clang: Kilograms.gen.hpp:35: error: cannot default 'operator<=>' because type 'std::partial_ordering' was not found; include <compare> Which is exactly the kind of difference a generator must not leave to whoever includes its output. Nothing about the schema says which standard library the target uses. It went unseen because every test that compiles generated C++ takes the first of `g++` or `clang++` on PATH, and on a Linux runner that is GCC. macOS returning to the test matrix in #188 is what surfaced it: there `g++` is a shim for AppleClang, and the whole suite compiles against libc++. The exemplar test pins the header byte for byte, so it now carries the include too - which is what keeps this checked on every platform rather than only on the one whose standard library is strict about it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01UGHDsYaaTQdzVR4XBR6miu
|
Before (run 771,
After (this PR,
1832 total, 4 failed → 2 failed. So the missing What remains is not this PR's. No fix for it exists yet to port, and I am not writing one: the failing assertion is a frame-timing difference on macOS/arm64 that I cannot reproduce without a macOS runner, and by the workflow's own stated rule this suite should not be running there at all — I am spending the one re-run on it, for a reason rather than out of habit: the failure is a timing assertion, so if it is genuinely intermittent rather than deterministic on this runner, a second run answers that and lets this PR merge. If it fails again it is deterministic, and the decision above belongs to whoever owns the shared workflow. Why this matters beyond tidiness. #190's Generated by Claude Code |
|
Re-run done, and it answers the question: deterministic, not intermittent. Byte for byte the same result — 1832 total, That is the one re-run spent. I am not running it again, and I am not touching the test or the workflow — so this PR stands as it is: it fixes what it says it fixes, and Getting to zero needs a decision I should not make unilaterally, because each option costs something different:
Worth noting the cost while it is unresolved: Generated by Claude Code |
The exclusion works now - macOS run 34828747684 reported:
Excluding tests/Schema.Editor.UITests/Schema.Editor.UITests.csproj from the test run.
Schema.Editor.Test passed there, so the thirteen frameless tests still run
on macOS, and Schema.Test passed on all three frameworks. The only failures
left on that cell are Schema.Cpp.Test on net9.0 and net10.0, which is #191's
fix and not this branch's work.
Rather than wait for #191 to merge, its change is ported here so this PR can
go green on its own. It is copied verbatim - same placement, same comment -
so the two are byte-identical and merge without a conflict: the post-image
blob is 6d74192 on both sides. Once #191 lands this commit is a no-op.
Schema.Cpp.Test: 101/101.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015qxqZVzN8CJcDxTb5gtWua
mainis red on the macOS cell, which #188 put back in the matrix. Two of the four failures are this, and it is a real generator bug rather than anything about the runner.A generated semantic type defaults
operator<=>, which answers with one of the ordering types in<compare>. The header never included it:libstdc++ happens to have declared those types by the time the generated header is read and libc++ does not, so the type compiled under GCC and was refused by Clang. Nothing about the schema says which standard library the target uses, so that is not a difference a generator may leave to whoever includes its output.
Why it went unseen
Every test here that compiles generated C++ takes the first of
g++orclang++onPATH, and on a Linux runner that is GCC. On macOSg++is a shim for AppleClang and the whole suite compiles against libc++ — so #188 restoring the macOS cell is what surfaced it, not what broke it. The bug is as old as the emitted<=>.I reproduced it locally by putting a
g++onPATHthat execsclang++, which is the same shape macOS has.Schema.Cpp.Testgoes 100/101 → 101/101 under that shim, and stays 101/101 under real GCC.ExemplarSemanticTypeTestspins the header byte for byte, so it now carries the include too — which is what keeps this checked on every platform rather than only on the one whose standard library is strict about it.This does not make
maingreen on its ownThe other two macOS failures are in
Schema.Editor.Test—MenuTests.OpeningARecentFileLoadsItthrowsItem 'recent/recalled.schema.json' was not drawn in the most recent frame, an ImGui harness timing difference on macOS/arm64. Those tests should not be running on macOS at all. #188's own rule says UI test projects are Linux-only, and it implements that as:This repository's UI test project is
Schema.Editor.Test, not*.UITests, so the glob matches nothing here and the suite runs on every platform — 2m10s of the macOS job, and flaky on it.I have left that alone deliberately. The fix is either in the shared workflow's glob or in this repository's project name, and
.github/workflows/dotnet.ymlis the file #188 just made byte-identical across every ktsu .NET repository — editing it here would re-introduce exactly the drift that PR removed. That is a call for whoever owns the shared workflow.Why this is urgent rather than tidy
#190's release never published. #188 merged nine minutes after it and its run cancelled #190's
Analyze & Releasemid-flight (Releasestep skipped), then run 771 failed on macOS. Soktsu.schema.toolis still at 1.34.0, and matt-edmondson/Holotype#16 is waiting on 1.34.1 — it needs #190's fix for a quantity with a default, which three of its members have.🤖 Generated with Claude Code
https://claude.ai/code/session_01UGHDsYaaTQdzVR4XBR6miu
Generated by Claude Code