[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
2 files changed
tree: c839b82882ce6c432b1d83f865d684317815dc6c
  1. .bazelci/
  2. bazel/
  3. cc_bindings_from_rs/
  4. common/
  5. docs/
  6. examples/
  7. features/
  8. lifetime_analysis/
  9. lifetime_annotations/
  10. migrator/
  11. nullability/
  12. rs_bindings_from_cc/
  13. support/
  14. .bazelrc
  15. .gitignore
  16. BUILD
  17. Cargo.lock
  18. CODE_OF_CONDUCT
  19. CONTRIBUTING
  20. LICENSE
  21. MODULE.bazel
  22. README.md
  23. WORKSPACE.bzlmod
README.md

Crubit: C++/Rust Bidirectional Interop Tool

Build status

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.

Status

Support for calling FFI-friendly C++ from Rust is in progress.

Support for calling Rust from C++ will arrive in 2024H2.

Example

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.

Getting Started

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.

Building Crubit

$ 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

Using a prebuilt LLVM tree

$ 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