commit | 5950ee85a170860fba24741a7674624930c732f8 | [log] [tgz] |
---|---|---|
author | Martin Brænne <mboehme@google.com> | Wed Jun 26 06:44:59 2024 -0700 |
committer | Copybara-Service <copybara-worker@google.com> | Wed Jun 26 06:46:45 2024 -0700 |
tree | c839b82882ce6c432b1d83f865d684317815dc6c | |
parent | 7b2ef7551c28ed26731c54d3a9f59aca90703470 [diff] |
[nullability] Rework the way we ensure raw pointers are initialized. We’re making this more consistent with smart pointers in that we give our transfer functions a chance to initialize the pointer first and only create a “backup” value if the transfer functions didn’t initialize the pointer. I was prompted to make this change when I observed that, for raw pointer glvalues, `ensurePointerHasValue()` would create a storage location if necessary but not associate it with the expression. This seemed like a simple fix, but merely adding an `Env.setStorageLocation()` caused failures because `modelGetReferenceableValue()` was now trying to set a storage location for an expression that already had one. This can be fixed by moving `ensurePointerHasValue()` until after the transfer function has run, which makes things more consistent with the treatment of smart pointers too. To emphasize the distinction between raw and smart pointers, I am renaming `ensurePointerHasValue()` to `ensureRawPointerHasValue()`. Some transfer functions previously assumed that the expression they operate on was already guaranteed to be associated with a pointer. Now, transfer functions need to take care of this themselves if necessary. To do this, I am providing an overload of `ensureRawPointerHasValue()` that takes an expression and returns the pointer associated with that expression (either an already existing pointer or a newly created one). PiperOrigin-RevId: 646927739 Change-Id: Id05e9fff268127814606b97dadd7cd9c995eed97
NOTE: Crubit currently expects deep integration with the build system, and is difficult to deploy to environments dissimilar to Google's monorepo. We do not have our tooling set up to accept external contributions at this time.
Crubit is a bidirectional bindings generator for C++ and Rust, with the goal of integrating the C++ and Rust ecosystems.
Support for calling FFI-friendly C++ from Rust is in progress.
Support for calling Rust from C++ will arrive in 2024H2.
Consider the following C++ function:
extern "C" bool IsGreater(int lhs, int rhs);
This function, if present in a header file which is processed by Crubit, becomes callable from Rust as if it were defined as:
pub fn IsGreater(lhs: ffi::c_int, rhs: ffi::c_int) -> bool {...}
Note: There are some temporary restrictions on the API shape. For example, functions that are not extern "C"
, or that accept a type like std::string
, can't be called from Rust directly via Crubit. These restrictions will be relaxed over time.
Here are some resources for getting started with Crubit:
Rust Bindings for C++ Libraries is a detailed walkthrough on how to use C++ from Rust using Crubit.
The examples/cpp/
directory has copy-pastable examples of calling C++ from Rust, together with snapshots of what the generated Rust interface looks like.
$ apt install clang lld bazel $ git clone git@github.com:google/crubit.git $ cd crubit $ bazel build --linkopt=-fuse-ld=/usr/bin/ld.lld //rs_bindings_from_cc:rs_bindings_from_cc_impl
$ git clone https://github.com/llvm/llvm-project $ cd llvm-project $ CC=clang CXX=clang++ cmake -S llvm -B build -DLLVM_ENABLE_PROJECTS='clang' -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=install $ cmake --build build -j $ # wait... $ cmake --install build $ cd ../crubit $ LLVM_INSTALL_PATH=../llvm-project/install bazel build //rs_bindings_from_cc:rs_bindings_from_cc_impl