2026-08-23 11:45:40 +09:00
|
|
|
---
|
|
|
|
|
name: gdext-verify-live-docs
|
2026-08-23 13:18:54 +09:00
|
|
|
description: Verify gdext (Godot Rust bindings) API calls against live docs, not recall.
|
2026-08-23 11:45:40 +09:00
|
|
|
---
|
|
|
|
|
|
|
|
|
|
# gdext: verify against live docs, don't trust recall
|
|
|
|
|
|
|
|
|
|
`gdext` is pre-1.0 and under active development — breaking changes between versions are routine, not
|
|
|
|
|
exceptional. Training-data recall of its API is likely to be stale in exactly the way that looks
|
|
|
|
|
correct: a plausible macro invocation or trait bound that compiled against an earlier version and
|
|
|
|
|
silently doesn't against the one actually in use.
|
|
|
|
|
|
|
|
|
|
**Before writing gdext-specific code (a `#[derive(GodotClass)]`, `#[godot_api]` block, signal
|
|
|
|
|
registration, an exported property, or any other gdext macro/trait), check the version actually
|
|
|
|
|
pinned in the project's `Cargo.toml`, then verify the API against:**
|
|
|
|
|
|
|
|
|
|
- `https://docs.rs/gdext` — pin the query to the pinned version, not `/latest`, if the two differ.
|
|
|
|
|
- `https://godot-rust.github.io/book` — the official book; tutorials and patterns change with the
|
|
|
|
|
crate, so prefer the version-matched section over a remembered pattern.
|
|
|
|
|
|
|
|
|
|
If a build fails on a gdext API call that looks like it should work, the first hypothesis is a
|
|
|
|
|
version mismatch between what's remembered and what's pinned — check the docs at the pinned version
|
|
|
|
|
before assuming the code is wrong.
|
|
|
|
|
|
|
|
|
|
Do not treat this skill as a place to cache gdext API details for next time. Anything gdext-specific
|
|
|
|
|
written here would go stale the same way recall does — the whole point is redirecting to a source
|
|
|
|
|
that stays current on its own.
|