Expand description
AD.3: examples for the plugin-API reference, extracted from guests CI already builds.
An example is a region of a real guest’s source, marked in place:
// @example grammar-callbacks.apply-operator: Toggle comments over a range
fn apply_operator(...) -> Result<Vec<Effect>, String> { ... }
// @end-exampleThe target is <interface>, <interface>.<function> (a method is
<interface>.<resource>.<method>, as the reference names it) or
<interface>.<type>. Regions are scanned from plugins/*/src and
crates/lattice-plugin-host/tests/fixtures/*/src — both compiled against the
current wit/ by lattice-plugin-host’s build script, which fails the
build when a guest does not compile and the wasm target is installed (as
it is in CI). So an example here compiles, and the fixture ones also run
under real guest↔host tests.
Why scanned at test time, not in build.rs with the catalog. The
catalog is compiled into lattice-plugin-api, which lattice-host links.
Declaring every guest source as a build input would make any edit to a
plugin or fixture rebuild this crate and so relink the whole host — the
exact cost lattice-plugin-host/build.rs documents paying once already.
The price of scanning here instead: the editor’s in-app
:export-plugin-api renders the reference without examples; the published
pages, the JSON and the agent bundle carry them.
Structs§
- ApiExample
- One extracted example.
- Examples
- Every example found, plus every malformed region — reported together so one test run names all of them.
Constants§
- GUEST_
ROOTS - The directories whose immediate subdirectories are guest crates, relative to the repository root.
Functions§
- scan
- Scan every guest under
GUEST_ROOTSin the repository atrepo_root.