Skip to content

About the reference

The reference is generated from the code itself, on every build. Nothing on these pages is hand-written, so nothing on them can drift from what the code actually says.

PageGenerated fromVia
ABI typesrust/fznso-typesrustdoc JSON
ABI entry pointsrust/fznso-solver-templaterustdoc JSON
Rust bindingsrust/fznsorustdoc JSON
C++ bindingscpp/fznso.hppDoxygen XML
C++ solver exportcpp/fznso_export.hppDoxygen XML
Python bindingspython/src/lib.rsgriffe

There is no separate C reference, by design.

c/fznso_types.h is generated from rust/fznso-types by cbindgen, so the C struct and the Rust type are the same declaration with two spellings. Documenting them twice would be the duplication this documentation is organised to avoid, and the copy that drifted would be the one a C programmer read.

So ABI types is the C reference as much as the Rust one. Where the two spellings differ (FznsoPtr<'a, T> in Rust is const FznsoX * in C), the difference is C-ABI-neutral and the header is the authority on the C form.

Each entry shows its signature, its documentation, and a link to the line of source it came from. Members (struct fields, enum variants, methods, properties) are listed under the type that owns them, and each has its own anchor, so the specification can link straight to a single callback.

The filter box at the top of each page narrows within that page. The site search covers all of them at once, alongside the guides, the specification and the registry.

The reference describes; the specification governs.

A doc comment states the contract of one function, type or field. Rules that span the interface (what a handle is, how long a borrow lasts, what a multi-threaded solver may do) are specified once in the spec, and the reference links to it rather than restating it. Where the two ever disagree, the specification is what an implementation is measured against.