Google Git
Sign in
bazel / crubit / 84c4c5820433d1340fb717c61dd6a3bc8201ec1c
commit84c4c5820433d1340fb717c61dd6a3bc8201ec1c[log] [tgz]
authorDevin Jeanpierre <jeanpierreda@google.com>Fri Feb 02 01:40:30 2024 -0800
committerCopybara-Service <copybara-worker@google.com>Fri Feb 02 01:41:21 2024 -0800
tree369a42eb670b13e86d749c85b28b6f431394c3cf
parent2cc7467874c6649ae2fd10c47c1829605c503cdd [diff]
Universalize the type alias passthrough workaround.

With this change, if the bindings for the type alias are disabled, we see through the type (if we can), across the board.

The only exceptions are if it has an unknown attribute, or is in a target that doesn't support Rust. These are explained in more detail in the comments.

... actually, those exceptions mean that this change is a no-op!

**However**, it will not be a no-op if we add new reasons to disable bindings. Indeed, I intend to add one in a followup CL, which is similar to the nested type case: if the parent type is unsupported, then typedefs should still "see through". Refactoring the logic in this way makes that followup CL a fair bit easier, because the decision happens all in one place instead of distributed across the bindings generation.

PiperOrigin-RevId: 603618082
Change-Id: Ib73b123a3abd22d1c5344f832aad0b7d5f6a69a8
2 files changed
tree: 369a42eb670b13e86d749c85b28b6f431394c3cf
  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. README.md
  22. WORKSPACE
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. With Crubit, Rust can be used anywhere C++ can be, directly calling and being called by C++. Crubit does not require wrapping C++ or Rust libraries in “FFI-friendly”, simplified APIs. Any C++ interface can be called or implemented by Rust code.

Current status: Crubit is aiming for an initial stable “MVP” version, comparable to bindgen and cbindgen. This will support basic datatypes like integers and pointers, (rust-movable) structs/unions/enums, and extern "C" functions.

Example

Consider the following C++ function:

extern "C" bool IsAbsPath(std::string_view path);

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 IsAbsPath(path: std::string_view) -> bool {...}

There are some temporary restrictions on the API shape. For example, if path were a std::string, or a non-extern "C" function, it would not be callable from Rust directly via Crubit. (For example, std::string is not rust-movable.) These restrictions will be relaxed over time.

For actual copy-pastable examples on getting started with Crubit, see the examples/ subdirectory. examples/cpp includes code which actually calls C++ via Crubit, and a snapshot of what the generated 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