Crubit, C++/Rust Bidirectional Interop Tool

The introduction of Crubit adds an automated step to the build process that produces interlanguage bindings for both directions, replacing the usual manual FFI scaffolding. By feeding Rust source files or C++ headers into Crubit, developers receive header files and Rust modules that expose the opposite language's API. This change streamlines cross-language integration, especially for teams that maintain mixed codebases. The tool’s status page lists which language constructs are already covered, giving a clear view of current capabilities.

Adopting Crubit means adding a code-generation phase, which may require a specific compiler version or nightly builds as indicated by the test matrix. Projects must incorporate the generated headers into their C++ compilation and the generated Rust modules into Cargo builds, potentially adjusting include paths and linking settings. The cost is primarily the initial setup and the need to monitor the supported feature list for any gaps that could require fallback to hand-written bindings.

Crubit’s bindings translate Rust references to const references in C++, and Rust string slices become a C++ string-reference wrapper, preserving ownership semantics across the language boundary. Conversely, C++ types like std::optional and std::unique_ptr are mapped to Rust’s Option and unique_ptr abstractions, allowing idiomatic use on both sides. These mappings are demonstrated in the provided examples, showing concrete usage patterns that developers can copy into their own code.

Where Crubit stops working is defined by the features not yet listed on its status page; complex generic types, certain lifetime annotations, or advanced template patterns may lack automatic support. In such cases, developers will need to write custom FFI code or wait for future releases. Understanding these limits is essential to avoid integration surprises and to plan incremental migration of existing interop layers.