flan/test/programs/raylib-imported.flan
Joseph Ferano e12e3e11c5 A table for the importer, against a header that does not move
Nothing in dune test exercised cimport.ml or cjson.ml. The raylib case is the
better evidence and the worse coverage: it needs raylib installed, at the
version whose .so is linked, with FLAN_RAYLIB_H set, so as the only test of
this it would skip everywhere and cover nothing.

test/headers/sample.h is one function per decision the importer makes, and the
table asserts on the reasons rather than the counts — a refusal that fires for
the wrong cause still refuses, and a count still matches. Accepted: an
aggregate in and out, const char * as a string, a pointer parameter, a second
typedef name for a record described once, a C enum against a defenum. Refused,
each by reason: a returned char *, a non-const char * C may write through, a
variadic, a callback, a long, a struct with no defstruct, and a kebab
collision. Plus that nothing is in both lists, which is the bug the collision
case found.

check_structs and diff_bound get a row each for agreeing, for a permuted field
order, for a widened field, and for a symbol the header does not have — the
last being how a package pinned to the wrong release announces itself. The
name rule and the JSON reader get their own rows.

Checked by breaking two of them on purpose and watching both fail.

test/programs/raylib-imported.flan is the end-to-end evidence, back and in the
new struct-literal spelling: four bindings the package does not bind by hand.
ColorToInt of {17,34,51,68} is 0x11223344 and ColorTint by white hands the four
bytes back separately, so field order is pinned by arithmetic and not by a
round trip, which is the trap BUILT.md records.
2026-09-12 16:09:48 +07:00

37 lines
1.5 KiB
Plaintext

;;;; Every binding called here came out of raylib's header, not out of
;;;; raylib.flan. The package binds none of these four by hand, so if this
;;;; program runs at all the importer produced working declarations — and
;;;; what it prints pins rather more than that.
;;;;
;;;; Needs FLAN_RAYLIB_H pointing at a raylib 5.5 header; the acceptance case
;;;; skips without it.
(import rl "vendor:raylib")
(defn main [] i32
;; A scalar in, a scalar out. Seeded, and a range of one, so the answer is
;; the bound rather than anything random.
(rl/set-random-seed 12345)
(println (rl/get-random-value 10 10))
;; A string parameter. A Flan string is ptr+len and never NUL-terminated, so
;; this only answers 5 if the generated wrapper made the terminated copy.
(println (rl/text-length "hello"))
;; A struct by value in, a scalar out. 0x11223344 is 287454020, and it is
;; the four fields read in r,g,b,a order — swap any two and the number
;; changes, which a round trip could not have told us.
(println (rl/color-to-int (rl/Color {.r 17 .g 34 .b 51 .a 68})))
;; A struct in and a struct out, which is the whole flattening path: the
;; argument goes by pointer and the result comes back through an
;; out-parameter. Tinting by white is the identity, so the four bytes come
;; back separately and in order.
(let [t (rl/color-tint (rl/Color {.r 255 .g 255 .b 255 .a 255})
(rl/Color {.r 17 .g 34 .b 51 .a 68}))]
(println (.r t))
(println (.g t))
(println (.b t))
(println (.a t)))
0)