Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
This PR implements the headers for the C API manually and removes the dependency on
cbindgen
.This needs rebasing on top of #14340.
Details
The header structure here is proposed as
Why remove
cbindgen
?cbindgen
is a tool we currently use to automatically generate the header for the C FFI for Rust, off the.rs
files that expose Rust structs, enums and functions. It's been super useful in starting the C API, but we're already hitting some limitations and expecting some more serious limitations in the future. The two main points IMO are:cbindgen
treats all objects as part of a global namespace: this means that trying to expose an objectsome_namespace::Thing
to C only works if there is no other object calledThing
in the parsed Rust API. This is a fundamental limitation incbindgen
, which they also mention in their docs.cbindgen
. But that requires active PR and issue reviews.Smaller problems we can work around (but that get a bit annoying and sum up):
cbindgen
pulls the Rust docs of objects we expose as opaque pointers. For example, we exposeSparseObservable
astypedef struct SparseObservable SparseObservable
to C, which causes the header to include the Rust docstring. We currently solve this by manually writing the Sphinx docs for these objects. This also affects enums we directly expose, such asBitTerm
.cbindgen
s export control.Why keep
cbindgen
?cbindgen
(as we're trying with Allow excluding prefixes for objects mozilla/cbindgen#1064). The global namespace could be a dealbreaker in the longer run, though.Todos
QkComplex64
to the C API #14340, once merged