| commit | 2495238521651a34b79f08c8e13ed457dbfb5474 | [log] [tgz] |
|---|---|---|
| author | Martin Brænne <mboehme@google.com> | Mon Jun 24 23:40:10 2024 -0700 |
| committer | Copybara-Service <copybara-worker@google.com> | Mon Jun 24 23:42:09 2024 -0700 |
| tree | 9dc8e992d4637fda4a09abe7094bf9e351b3f46a | |
| parent | 113775f4172dbbc9ccd563d98b5d32a8fa197a03 [diff] |
[nullability] Split diagnosis into two callbacks. The framework recently added the ability to run post-analysis callbacks not just on the state after the transfer function for a `CFGElement` has been run but also before it. Conceptually, diagnostic callbacks usually make more sense to run on the "before" state because we usually want to check preconditions for the operation, so almost all diagnostics are now run in this way. This makes the diagnostic callback for smart pointers more intuitive: When we were running this on the "after" state, to check whether we were assigning a nullable pointer to a nonnull variable, we somewhat unintuitively had to check the nullability of the _left-hand_ side (because the right-hand side of a smart pointer assignment is always null after the assignment has been carried out). Now that the callback is running on the "before" state, we can more intuitively check the nullability of the right-hand side. More importantly, this will enable us to perform diagnosis correctly on the `++` and `--` operators. For these, we need to access the "before" state to check whether the pointer being incremented is nullable. (The "after" state of the pointer is always non-null.) There is one check that we are still running on the "after" state, namely `diagnoseMovedFromNonnullSmartPointer`. This needs to be run on the "after" state because in the "before" state, the pointer and its nullability properties may not yet be initialized. PiperOrigin-RevId: 646351557 Change-Id: Ib51e4d236bfc8662f55ef3e6537d65bb1a9d0c57
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