Google Git
Sign in
bazel / crubit / 550ecae126d3a79e41b63f9e9f702643c15edd12
commit550ecae126d3a79e41b63f9e9f702643c15edd12[log] [tgz]
authorDevin Jeanpierre <jeanpierreda@google.com>Tue Jul 23 00:28:16 2024 -0700
committerCopybara-Service <copybara-worker@google.com>Tue Jul 23 00:29:50 2024 -0700
tree8088f9ba0c97ebf8bafd3a575c82403fa4de73bd
parent1d936b1ddd6cf3a5a087ca42bb7f183afc507d83 [diff]
Fix b/333737712: incorrect namespace assignment for items in reopened namespaces.

This ended up being a pretty simple problem after all. We do have independent namespace decl IDs for the original vs reopened namespace, so there _is_ an item ID that the nested declaration could be assigned as a parent -- it just was assigned the wrong one. Why? Well, the previous version of the code used `getEnclosingNamespaceContext`, which loops over the parents until it finds the namespace, and then returns the _canonicalized_ namespace decl: the _first_ namespace decl with that name, not the actual direct parent, which might be a redeclaration. The fix, then, is to not use `getEnclosingNamespaceContext`, but to reproduce the same loop in our code.

PiperOrigin-RevId: 655052095
Change-Id: Ic2b8c85f65a8bdb6f4de55f61231bc5f3ef49e47
6 files changed
tree: 8088f9ba0c97ebf8bafd3a575c82403fa4de73bd
  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