Emit evidence for virtual methods and overrides that constrain each other.

The nullabilities of return and parameter types for these functions are partially constrained by the overriding/overridden method(s). So when collecting evidence for one, collect the same evidence for the overriding or overridden method as appropriate for that constraint.

Because callers can virtually call Derived::foo or Base::foo from a Base object and can call only Derived::foo from a Derived object (without very explicitly referencing the Base method decl), the Derived API can be only as restrictive as the Base API from the *caller's* perspective in terms of what it can return or what it accepts for parameters. Derived::foo can be less restrictive, or equally restrictive, but not more, e.g. Derived::foo can accept Nullable parameters instead of just Base::foo's Nonnulls, but Derived::foo can't require Nonnull parameters instead of Base::foo's allowed Nullables.

Therefore, we apply the following rules for evidence collection. For return types, evidence pointing towards Nonnull emitted for Base methods is emitted also for Derived methods and evidence pointing towards Nullable emitted for Derived methods is emitted also for Base methods. For parameter types, this is flipped. See the many tests in this change for examples of evidence collected and inferences made in various scenarios.

PiperOrigin-RevId: 646930709
Change-Id: I541ec5b9973d80f26114e53f81d9fbfae38ff24c
5 files changed
tree: 65a18fb99480df7d88b0f1e3a313a2313670d703
  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