Modernize bindings for Mojo 1.2

.github/workflows/ci.yml

@@ -27,7 +27,22 @@ jobs:
           sudo apt-get install -y clang libclang1
 
       - name: Validate repository
-        run: pixi run check-light
+        run: pixi run --locked check-light
         env:
           # Help libclang find the system shared library on Ubuntu runners.
           LD_LIBRARY_PATH: /usr/lib/x86_64-linux-gnu
+
+  ffi-runtime:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+      - name: Install Pixi
+        uses: prefix-dev/setup-pixi@v0.8.14
+        with:
+          cache: true
+      - name: Install C toolchain
+        run: sudo apt-get update && sudo apt-get install -y clang libclang1
+      - name: Verify generated FFI on locked Mojo
+        run: pixi run --locked pytest -q tests/e2e
+        env:
+          LD_LIBRARY_PATH: /usr/lib/x86_64-linux-gnu

CONTRIBUTING.md

@@ -14,6 +14,7 @@ emits Mojo FFI bindings. Most contribution work falls into one of three areas:
 The repository currently targets:
 
 - Python 3.14+
+- Mojo 1.2+ (1.x), with the exact development version selected by `pixi.lock`
 - a system `libclang` compatible with the Python `libclang` wheel
 - Linux for the full Pixi + Mojo workflow
 
@@ -25,7 +26,7 @@ The workspace is currently locked for `linux-64` only. On other platforms, use
 a normal virtualenv and `pip install -e ".[dev]"` instead.
 
 ```bash
-pixi install
+pixi install --locked
 pixi shell
 pixi run lint
 pixi run format
@@ -38,6 +39,8 @@ Useful Pixi tasks:
 - `pixi run test`: full pytest suite
 - `pixi run test-light`: pytest excluding `expensive` tests
 - `pixi run check-light`: CI-aligned validation (`format-check`, lint, pyright, `test-light`)
+- `pixi run --locked pytest -q tests/e2e`: the separate FFI runtime CI gate,
+  including compiler warnings as errors and negative vararg compilation checks
 - `pixi run build`: build sdist and wheel
 - `pixi run example-sqlite` / `example-cairo` / `example-libpng` / `example-zlib`: generate and exercise example bindings
 

README.md

@@ -14,7 +14,7 @@ correctly.
 
 - Python 3.14+
 - a system `libclang` compatible with the `libclang` Python wheel
-- a Mojo 1.0+ toolchain if you want to build or run the generated bindings
+- a Mojo 1.2+ toolchain (1.x) to build or run generated bindings
 
 ## Installation
 
@@ -151,8 +151,9 @@ Current support includes:
 - **Callbacks and function pointers:** callback typedefs, function-pointer
   fields, and function-pointer parameters and returns are preserved in Mojo via
   emitted `comptime` callback declarations and synthesized aliases when needed.
-- **Functions:** thin wrappers are generated for non-variadic functions under
-  both `external_call` and `owned_dl_handle` link modes.
+- **Functions:** thin wrappers are generated under both link modes. Dynamic calls
+  use public, owner-borrowing `OwnedDLHandle` callables. Checked variadic wrappers
+  are available in `external_call` mode.
 - **Globals and constants:** because Mojo does not currently expose native C
   globals directly, supported globals map through generated `GlobalVar` /
   `GlobalConst` helper structs with synthesized `load()` / `store()` methods;
@@ -171,8 +172,9 @@ verify emitted layouts and symbols against your target toolchain.
 - **Macros:** function-like macros, predefined macros, and more complex
   preprocessor behavior are preserved but usually emitted as comments for
   end-user review.
-- **Variadics:** variadic C functions are not wrapped as callable thin-FFI
-  bindings yet and are emitted as comment stubs.
+- **Variadics:** direct-call wrappers require exact declared types for the fixed
+  prefix and explicitly promoted C types for the tail. Dynamic-mode variadics
+  remain comment stubs because `OwnedDLHandle` has no variadic ABI metadata.
 - **Non-prototype / K&R-style functions:** older C declaration styles are only
   partially modeled and should be treated with caution.
 - **Records with hostile layouts:** some packed, ABI-sensitive, or otherwise
@@ -184,7 +186,10 @@ verify emitted layouts and symbols against your target toolchain.
   record surface.
 - **Atomics:** atomic support is conservative. Representable atomic fields and
   pointer-based usage work, but atomic globals are still emitted as stubs and
-  some surfaces require manual handling.
+  some surfaces require manual handling. Bindings use `Atomic[T]`; incompatible
+  atomic storage is opaque and is never silently treated as non-atomic storage.
+- **By-value returns:** a mapped return type must be `RegisterPassable`. Returns
+  containing fixed arrays or opaque storage are emitted as diagnostic stubs.
 - **Linkage and compiler edge cases:** `inline`, compiler-specific linkage
   hints, and other extension-heavy cases can still require manual review and
   may lead to symbol mismatches at runtime.