tests/test_source_invariants.cpp opens the production sources and asserts
that a fixed pattern is absent — or that a required one is present. 76
checks run from its main(). They exist because this plug-in's worst bugs
are not type errors: they are a lock held one line too long, a strong pointer
where a weak one belonged, an #ifdef that silently stopped meaning anything.
A compiler cannot see any of those. A scanner over the source can.
Each check uses the file's own helpers — slurp to read a production file by
path, strip_line_comments so prose about a bug is not mistaken for the bug,
function_body to isolate one function, scope_from to walk a lexical scope,
and check(condition, message) to record a failure.
Three properties separate a check that earns its place from one that will be
deleted at the first inconvenience:
It must be provably failable. Reinstate the bug, run the suite, watch it
fail. Every check here has been through that, and two of them turned out
not to fire at all until mutation said so.
It must be non-vacuous. A scan whose pattern stops matching reports
clean. So each carries a floor — "this must still find at least N sites" —
and where a global floor would let one file's sites hide behind another's,
the floor is per file.
It must not cry wolf. A check that flags correct code gets deleted. One
here escapes legitimate cases by shape (a validator named Is*/
Validate*/Check* one call deeper) rather than by "any preceding call",
because the broader escape would have hidden a real defect.
Most run on comment-stripped and often whitespace-flattened source, so a
pattern cannot be defeated by wrapping a call across four lines — or by
clang-format joining it onto one.
a default argument on an ISE* method must match its implementation's — the compiler does not check this and the call site silently gets whichever it sees
the SDK is never built with its Authenticode verification skipped
check_wyvrn_sdk_calls_stay_on_the_sdk_thread
the Chroma stack beneath it is COM-based and thread-affine
check_wyvrn_init_reports_its_outcome_to_analytics
both CoreInitSDK outcomes fire their event with the status vocabulary and field names the dashboard reads, and the two paths with no result — no usable SDK, and a shutdown mid-call — stay silent
the event timestamp and the workers' stop flag are atomic, the timestamp is taken with one exchange, and the subtraction after it is guarded against the reordering that exchange does not prevent
clang promotes -Wnewline-eof to an error under -Werror; one missing byte failed a macOS build out of 95 translation units
check_no_platform_guard_uses_the_bare_APPLE_macro
APPLE is a CMake variable, not a compiler define — three #ifdef APPLE branches had never been compiled, and one made a host API method answer false on macOS while doing nothing
Read the message: each one states the rule and, usually, the incident. Then
decide which of two things is true — the change reintroduced the pattern, or
the rule has genuinely moved. If it is the second, the check is the place to
record the new rule, and the commit should say why the old one stopped
applying. Do not loosen a check to make a build green; a check that cannot
fail is worth nothing, and the only way to know which kind you have is to
mutate the source and watch.