Two gaps the raylib examples hit. The layout check compared a Flan enum against the header's `int` and called it a disagreement. It is not one: Shim.cty lowers a defenum to int32_t in a struct field exactly as it does in a parameter, which is what the signature check already knew and the layout check did not. One predicate now serves both, symmetric, and tolerant of a 32-bit integer and nothing else -- f64 against the library's float still fails, in the very struct whose other field is an enum. Camera3D.projection is a CameraProjection again and rl/camera-projection is gone with it, so `.projection :perspective` resolves at the construction site. And generate-c's claim said nothing about a defconst or a defenum member, so a wrong flag bit was completely silent. `bindings` gained `enum`, `const` and `constant` lines saying what a Flan constant is called in C -- the prefix is nowhere in the Flan name, so it is declared rather than guessed. Nothing goes quiet in either direction: a name the rule builds and the header lacks is reported, a rule that reaches nothing is reported, and a defenum with no line is itself a finding, because otherwise the silence just moves up one level. clang's dump gives anonymous EnumDecls for every raylib enum and no value at all for an enumerator written without `= n`, so the constants are one flat table and the values are counted the way C counts them. cache_format bumped with the dump type.
Description
Languages
OCaml
67.2%
Emacs Lisp
15.2%
C
10.4%
HTML
2.9%
Standard ML
2.8%
Other
1.5%