commit | e1ddd19c178ba735133c7ebc625301ceba8c6a6a | [log] [tgz] |
---|---|---|
author | Googler <no-reply@google.com> | Wed Jun 26 06:56:48 2024 -0700 |
committer | Copybara-Service <copybara-worker@google.com> | Wed Jun 26 06:58:08 2024 -0700 |
tree | 65a18fb99480df7d88b0f1e3a313a2313670d703 | |
parent | 5950ee85a170860fba24741a7674624930c732f8 [diff] |
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
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