Proto commits in google/crubit

These commits are when the Protocol Buffers files have changed: (only the last 100 relevant commits are shown)

2026-08-20

Represent item ids as an **unsigned** integer. This avoids the following ClangTidy warnings: > implicit conversion changes signedness: 'ValueType' (aka 'unsigned long') to > '::int64_t' (aka 'long') Which otherwise would be reported in a handful of places like: https://github.com/google/crubit/blob/ff8c61cc3c6a4bc0a0bba754e6e94a5ed57d1806/rs_bindings_from_cc/importers/enum.cc#L180 PiperOrigin-RevId: 967998911

2026-08-18

Remove `has_c_calling_convention` field from `Func` in `rs_bindings_from_cc/ir.proto` and add helper function that checks `call_conv`. PiperOrigin-RevId: 966697157

2026-08-17

Support non-standard calling conventions for function signature checks - Move `ConvertCcCallConvToSupportedCallingConv` from `rs_bindings_from_cc/importer.cc` to `rs_bindings_from_cc/ast_util.h` and `rs_bindings_from_cc/ast_util.cc` - Add `CallingConv call_conv` field to `Func` in `rs_bindings_from_cc/ir.proto` - For supported non-standard calling conventions add flag to assertion in `rs_bindings_from_cc/generate_bindings/generate_function_thunk.rs` - Add case for `clang::vectorcall` and `win64` in `rs_bindings_from_cc/test/golden/nonstandard_calling_convention*` PiperOrigin-RevId: 966033485

Support non-standard calling conventions for function signature checks - Move `ConvertCcCallConvToSupportedCallingConv` from `rs_bindings_from_cc/importer.cc` to `rs_bindings_from_cc/ast_util.h` and `rs_bindings_from_cc/ast_util.cc` - Add `CallingConv call_conv` field to `Func` in `rs_bindings_from_cc/ir.proto` - For supported non-standard calling conventions add flag to assertion in `rs_bindings_from_cc/generate_bindings/generate_function_thunk.rs` - Add case for `clang::vectorcall` and `win64` in `rs_bindings_from_cc/test/golden/nonstandard_calling_convention*` PiperOrigin-RevId: 965593089

2026-08-12

Add support for std::atomic in Crubit. Note that std::atomic and std::atomic intentionally fall back to opaque bindings. Rust's standard library does not provide an AtomicCLong. Because long is 32-bit on Windows LLP64 and 64-bit on Linux LP64, hardcoding it to AtomicI64 or AtomicI32 would cause stack corruption across the FFI boundary. Consequently, std::atomic<size_t> will also become opaque on 64-bit Linux because Clang canonicalizes it to unsigned long. Users should prefer std::atomic<uintptr_t> or std::atomic<uint64_t> for cross-language atomics. PiperOrigin-RevId: 963537848

2026-08-10

Add support for std::atomic in Crubit. Note that std::atomic and std::atomic intentionally fall back to opaque bindings. Rust's standard library does not provide an AtomicCLong. Because long is 32-bit on Windows LLP64 and 64-bit on Linux LP64, hardcoding it to AtomicI64 or AtomicI32 would cause stack corruption across the FFI boundary. Consequently, std::atomic<size_t> will also become opaque on 64-bit Linux because Clang canonicalizes it to unsigned long. Users should prefer std::atomic<uintptr_t> or std::atomic<uint64_t> for cross-language atomics. PiperOrigin-RevId: 920404627

2026-08-07

rs_bindings_from_cc: add a label hint to the CRUBIT_BRIDGE annotation in support for use_label_encoded_names_for_deps PiperOrigin-RevId: 960835645

2026-08-06

shared_ptr_const attempt #2, with fixes. This previously broke because, in the name of type safety, I typed the `cntrl` block as `forward_declare::Incomplete<forward_declare::symbol!("std :: __u :: __shared_weak_count")>`, which is the Crubit "equivalent" of `std::integral_constant` but for strings. This allows us to "strongly type" pointers to types that don't exist in Rust. However, under certain conditions like running a test in tsan, `std::__shared_weak_count` expands to `std::__tsan::__shared_weak_count`, which when Crubit-mapped to Rust, becomes `forward_declare::Incomplete<forward_declare::symbol!("std :: __tsan :: __shared_weak_count")>`, a distinct type from what we expect, causing a compilation error. There are two solutions to this. The first is to make Crubit not expand inline namespaces, naming them both just `std::__shared_weak_count`. But the easier solution here is to just leave the `cntrl` block as type erased in Rust and add some safety comments. No AI was used in the fixing of this bug- any hallucinations are my own. PiperOrigin-RevId: 960474053

2026-08-05

Temporarily undo shared_ptr_const support because it broken tests running under tsan, which swap out the cntrl block type to something other than `std::__u::__shared_weak_count` PiperOrigin-RevId: 959895063

Crubit support for `shared_ptr<const T>`. Unlike unique_ptr, I think we don't need a separate virtual_shared_ptr, because the destructor is type-erased. But the other consequence of this is that, dang, it's pretty hard to create one from pure Rust. For now, there's no constructors at all, just the ability to consume and pass around a shared_ptr<const T>. (The code for non-const T would be similar.) The CL was _nearly_ one-shot with Gemini, but it overdid it in a few places and I've pared it back to what I think the CL should be. In particular, the invasive use of internal details of libc++ is _entirely_ my idea. The fact that we're relying on shared_ptr having the layout we expect is already digging into the implementation details: we need careful deployment/etc. of this with collaboration of libc++ deployment owners for this to be kept working. In the google monorepo, we got it, but probably this will need to be turned off outside Google... PiperOrigin-RevId: 959880429

Remove unused is_compiler_generated field from Crubit IR. PiperOrigin-RevId: 959865363

2026-08-04

Identify simple getters and setters and tag them in the IR. PiperOrigin-RevId: 959228882

Crubit support for `shared_ptr<const T>`. Unlike unique_ptr, I think we don't need a separate virtual_shared_ptr, because the destructor is type-erased. But the other consequence of this is that, dang, it's pretty hard to create one from pure Rust. For now, there's no constructors at all, just the ability to consume and pass around a shared_ptr<const T>. (The code for non-const T would be similar.) The CL was _nearly_ one-shot with Gemini, but it overdid it in a few places and I've pared it back to what I think the CL should be. In particular, the invasive use of internal details of libc++ is _entirely_ my idea. The fact that we're relying on shared_ptr having the layout we expect is already digging into the implementation details: we need careful deployment/etc. of this with collaboration of libc++ deployment owners for this to be kept working. In the google monorepo, we got it, but probably this will need to be turned off outside Google... PiperOrigin-RevId: 957386457

Identify simple getters and setters and tag them in the IR. PiperOrigin-RevId: 957395946

2026-08-03

Add support for std::atomic in Crubit. Note that std::atomic and std::atomic intentionally fall back to opaque bindings. Rust's standard library does not provide an AtomicCLong. Because long is 32-bit on Windows LLP64 and 64-bit on Linux LP64, hardcoding it to AtomicI64 or AtomicI32 would cause stack corruption across the FFI boundary. Consequently, std::atomic<size_t> will also become opaque on 64-bit Linux because Clang canonicalizes it to unsigned long. Users should prefer std::atomic<uintptr_t> or std::atomic<uint64_t> for cross-language atomics. PiperOrigin-RevId: 958552293

Crubit support for `shared_ptr<const T>`. Unlike unique_ptr, I think we don't need a separate virtual_shared_ptr, because the destructor is type-erased. But the other consequence of this is that, dang, it's pretty hard to create one from pure Rust. For now, there's no constructors at all, just the ability to consume and pass around a shared_ptr<const T>. (The code for non-const T would be similar.) The CL was _nearly_ one-shot with Gemini, but it overdid it in a few places and I've pared it back to what I think the CL should be. In particular, the invasive use of internal details of libc++ is _entirely_ my idea. The fact that we're relying on shared_ptr having the layout we expect is already digging into the implementation details: we need careful deployment/etc. of this with collaboration of libc++ deployment owners for this to be kept working. In the google monorepo, we got it, but probably this will need to be turned off outside Google... PiperOrigin-RevId: 957386457

2026-08-01

Crubit support for `shared_ptr<const T>`. Unlike unique_ptr, I think we don't need a separate virtual_shared_ptr, because the destructor is type-erased. But the other consequence of this is that, dang, it's pretty hard to create one from pure Rust. For now, there's no constructors at all, just the ability to consume and pass around a shared_ptr<const T>. (The code for non-const T would be similar.) The CL was _nearly_ one-shot with Gemini, but it overdid it in a few places and I've pared it back to what I think the CL should be. In particular, the invasive use of internal details of libc++ is _entirely_ my idea. The fact that we're relying on shared_ptr having the layout we expect is already digging into the implementation details: we need careful deployment/etc. of this with collaboration of libc++ deployment owners for this to be kept working. In the google monorepo, we got it, but probably this will need to be turned off outside Google... PiperOrigin-RevId: 957386457

Identify simple getters and setters and tag them in the IR. PiperOrigin-RevId: 957395946

2026-07-30

Remove legacy IR structs in ir.h This change entails: - Swapping miscellanous uses of C++ structs to ir_proto::* items - Adding helpers to proto-convert all identifiers synthetically appended to the IR. - Moved IR specification doc-comments to ir.proto PiperOrigin-RevId: 956710685

2026-07-29

Remove legacy IR structs in ir.h This change entails: - Swapping miscellanous uses of C++ structs to ir_proto::* items - Adding helpers to proto-convert all identifiers synthetically appended to the IR. - Moved IR specification doc-comments to ir.proto PiperOrigin-RevId: 954933379

Canonicalize the frontend IR to use the protobuf format, deprecating any C++ IR usage. This entails: - deleting `IR::ToFlatProto()` (ir -> protobuf serialization) - refactoring `get_items_if<T>` to be free template functions - IrFromCc outputs metadata fields on the FFI payload directly PiperOrigin-RevId: 955078132

2026-07-28

rs_bindings_from_cc: Add proto support to label-encoded crate names. PiperOrigin-RevId: 955131300

2026-07-27

rs_bindings_from_cc: Add proto support to label-encoded crate names. PiperOrigin-RevId: 952698603

2026-07-23

rs_bindings_from_cc: use label-encoded crate names for generated bindings of dependencies PiperOrigin-RevId: 952052132

WIP: directly implement primitive getters and setters PiperOrigin-RevId: 952457868

2026-07-22

Modify Crubit to natively generate inline_cpp! and global_cpp! PiperOrigin-RevId: 952345197

assume_lifetimes: adjust the heuristic that determines when a record is a view (N-arity) vs. an owner (0-arity); fix some small codegen issues Previously we assumed that records with [[lifetimebound]] were generally views, and needed an associated lifetime parameter. This isn't the case for, e.g., a struct that only wraps a std::string. Change the heuristic so that an unannotated record is assumed to have arity 0 if all of its fields are arity 0. (Since we don't import anything about private fields, we approximate their presence with a single bit that's set if any nonpublic fields are pointers or references. We plan on adding support for an explicit ABSL_ATTRIBUTE_OWNER (or similar) annotation). PiperOrigin-RevId: 952302620

Automate the generation of the Rust interface and write the files PiperOrigin-RevId: 952178565

assume_lifetimes: adjust the heuristic that determines when a record is a view (N-arity) vs. an owner (0-arity); fix some small codegen issues Previously we assumed that records with [[lifetimebound]] were generally views, and needed an associated lifetime parameter. This isn't the case for, e.g., a struct that only wraps a std::string. Change the heuristic so that an unannotated record is assumed to have arity 0 if all of its fields are arity 0. (Since we don't import anything about private fields, we approximate their presence with a single bit that's set if any nonpublic fields are pointers or references. We plan on adding support for an explicit ABSL_ATTRIBUTE_OWNER (or similar) annotation). PiperOrigin-RevId: 951842153

Add `carcinize` CLI tool for automated C++ to Rust migration PiperOrigin-RevId: 947706047

2026-07-21

Modify Crubit to natively generate inline_cpp! and global_cpp! PiperOrigin-RevId: 949213817

Delete the `json` field off GenerateBindingsRequest. This doesn't need to be reserved as json/proto format is an implementation detail, and this message is only used as an internal payload with no external consumers. PiperOrigin-RevId: 951624079

Add `carcinize` CLI tool for automated C++ to Rust migration PiperOrigin-RevId: 947706047

Modify Crubit to natively generate inline_cpp! and global_cpp! PiperOrigin-RevId: 949213817

2026-07-20

Modify Crubit to natively generate inline_cpp! and global_cpp! PiperOrigin-RevId: 949213817

2026-07-16

Modify Crubit to natively generate inline_cpp! and global_cpp! PiperOrigin-RevId: 949213817

2026-07-15

Preserve forward-declared enum semantics in protobuf IR by adding `is_incomplete` boolean field to the Enum message. When converting from C++ IR to protobuf IR, if `Enum::enumerators` does not have a value (an incomplete/forward-declared enum rather than a complete definition), `is_incomplete` is set to true. When deserializing in `proto_to_ir.rs`, if `is_incomplete` is set, `enumerators` should be set to None instead of an empty, existent vector, which previously resulted in invalid bindings for opaque enums. This should also matter once we migrate to wrap EnumView, since we'll have no way of distinguishing between `enum ForwardDeclared` and `enum Empty {}` from &[T] PiperOrigin-RevId: 948341164

2026-07-14

Enable the `use_protobuf_ir` feature. This adds the feature flag to the list of globally supported features in Crubit. PiperOrigin-RevId: 932474840

Set adl_enclosing_record on friend declarations in FunctionDeclImporter::Import. When a friend function is imported by `FunctionDeclImporter::Import`, compute and populate its `.adl_enclosing_record` from its lexical `CXXRecordDecl` context. Without `.adl_enclosing_record`, the bindings generator treats the friend function as a normal namespace function and emits a namespace-qualified call, which disables ADL and errors out as it doesn't exist in the namespace scope. PiperOrigin-RevId: 947915008

Preserve forward-declared enum semantics in protobuf IR by adding `is_incomplete` boolean field to the Enum message. When converting from C++ IR to protobuf IR, if `Enum::enumerators` does not have a value (an incomplete/forward-declared enum rather than a complete definition), `is_incomplete` is set to true. When deserializing in `proto_to_ir.rs`, if `is_incomplete` is set, `enumerators` should be set to None instead of an empty, existent vector, which previously resulted in invalid bindings for opaque enums. This should also matter once we migrate to wrap EnumView, since we'll have no way of distinguishing between `enum ForwardDeclared` and `enum Empty {}` from &[T] PiperOrigin-RevId: 947885916

Split the flag for support paths in two. One flag for non-versioned support libraries (should become "everything except internal"), one for versioned support libraries (should become just internal). It's useful to have the second flag refer directly into the `internal/` directory so that, as a migration trick, we get an error if we miss one (the path would be incorrect.) As such, this is only correct if unknown commit pans out, otherwise we'd need a third flag. (Specifically, for the rs_std includes, like dyn_callable and lossy_formatter_for_bindings). This is a prerequisite for eventually removing the whole `#include <crubit/foo>` thing, and replacing it with `#include "third_party/crubit/foo"`. First, we need to fix the generated code, which requires distinguishing between things that need the trick, and things that don't. (Unless we get rid of it entirely, I suppose.) PiperOrigin-RevId: 947564407

2026-07-13

Split the flag for support paths in two. One flag for non-versioned support libraries (should become "everything except internal"), one for versioned support libraries (should become just internal). It's useful to have the second flag refer directly into the `internal/` directory so that, as a migration trick, we get an error if we miss one (the path would be incorrect.) As such, this is only correct if unknown commit pans out, otherwise we'd need a third flag. (Specifically, for the rs_std includes, like dyn_callable and lossy_formatter_for_bindings). This is a prerequisite for eventually removing the whole `#include <crubit/foo>` thing, and replacing it with `#include "third_party/crubit/foo"`. First, we need to fix the generated code, which requires distinguishing between things that need the trick, and things that don't. (Unless we get rid of it entirely, I suppose.) PiperOrigin-RevId: 946783191

2026-07-09

`rs_bindings_from_cc` bindings: Support explicitly provided crate names. This CL supports Crubit clients where crate names are not directly based on a target name. For example, Chromium uses a mangling / hashing scheme to guarantee globally-unique crate names (see `chromium::import!` for more details). Together with https://crrev.com/c/8027730/1 this CL unblocks Chromium's ability to use transitive dependencies in `rs_bindings_from_cc`-generated bindings. PiperOrigin-RevId: 944789077

2026-07-08

Populate `impl_debug` in Crubit IR. Updates the importer to read the `crubit_override_debug` annotation on records, checks whether the `record_impl_debug` feature is enabled for the target, and populates the `impl_debug` boolean field in the IR. PiperOrigin-RevId: 944201431

2026-07-07

Add cfi_encoding attribute to generated enums, which are passed by value (and therefore need to have an encoding that matches the original C++). PiperOrigin-RevId: 944075367

Define `TemplateSpecializationKind`s for `absl::flat_hash_set` and `absl::flat_hash_map` and set them in the IR These will be used to customize the bindings for these types on the Rust side. PiperOrigin-RevId: 943990664

2026-07-06

Define `TemplateSpecializationKind`s for `absl::flat_hash_set` and `absl::flat_hash_map` and set them in the IR These will be used to customize the bindings for these types on the Rust side. PiperOrigin-RevId: 943381674

Add cfi_encoding attribute to generated enums, which are passed by value (and therefore need to have an encoding that matches the original C++). PiperOrigin-RevId: 941406195

Deprecate children_item_ids in the rs_bindings_from_cc's backend and test matchers. children_item_ids are no longer used in the backend to resolve the db IR, hence we remove them and refactor tests to use the children items directly. PiperOrigin-RevId: 943267094

2026-07-02

Remove deprecated top-level IR fields (flat items array & top_level_item_ids) from the rs_bindings_from_cc's backend and test matchers. These fields are no longer used in the backend to resolve bindings, and tests are updated to assert on the root top_level_items directly. This CL should be a no-op. PiperOrigin-RevId: 941842425

Deprecate serialization of child_item_ids in rs_bindings_from_cc. child_item_ids fields are no longer used in the backend following the restructure. We move them from the C++ IR to the Clang `Invocation` as they are now only used as an internal implementation detail in the importer. This finalizes the cleanup needed for the IR restructure in[] PiperOrigin-RevId: 941201400

Add cfi_encoding attribute to generated enums, which are passed by value (and therefore need to have an encoding that matches the original C++). PiperOrigin-RevId: 941406195

2026-07-01

Deprecate serialization of child_item_ids in rs_bindings_from_cc. PiperOrigin-RevId: 941201400

Populate `impl_debug` in Crubit IR. Updates the importer to read the `crubit_override_debug` annotation on records, checks whether the `record_impl_debug` feature is enabled for the target, and populates the `impl_debug` boolean field in the IR. PiperOrigin-RevId: 937701661

`rs_bindings_from_cc` bindings: Support explicitly provided crate names. This CL supports Crubit clients where crate names are not directly based on a target name. For example, Chromium uses a mangling / hashing scheme to guarantee globally-unique crate names (see `chromium::import!` for more details). Together with https://crrev.com/c/8027730/1 this CL unblocks Chromium's ability to use transitive dependencies in `rs_bindings_from_cc`-generated bindings. PiperOrigin-RevId: 940662918

Remove deprecated top-level IR fields (flat items array & top_level_item_ids) from the C++ IR struct. Following removal of top_level_item_ids from the Rust IR in the parent CL, this change removes the top_level_item_ids field from the C++ IR struct and IR::ToJson() serialization. Because of this, BuildTree() now accepts top_level_item_ids as a short-lived input parameter during AST import to populate top_level_items instead. PiperOrigin-RevId: 941103191

Populate `impl_debug` in Crubit IR. Updates the importer to read the `crubit_override_debug` annotation on records, checks whether the `record_impl_debug` feature is enabled for the target, and populates the `impl_debug` boolean field in the IR. PiperOrigin-RevId: 937701661

2026-06-30

`rs_bindings_from_cc` bindings: Support explicitly provided crate names. Together with https://crrev.com/c/8027730/1 this unblocks Chromium's ability to use transitive dependencies in `rs_bindings_from_cc`-generated bindings. PiperOrigin-RevId: 940662918

2026-06-29

Deprecate use of top_level/children item_ids Removes the top_level_item_ids field from the IR and other call-sites (except for the importer, which we avoid modifying to de-risk for regressions). PiperOrigin-RevId: 939827060

2026-06-26

Add support for C++ user-defined conversion operators. We map depending on the target type and pin/move characteristics: - Movable, locally-defined type (Record is Unpin and local to the crate): `operator Dst() const` => `impl From<&Src> for Dst` - Immovable, locally-defined type: `operator Dst() const` => `impl CtorNew<&Src> for Dst` - Foreign types, primitives, or reference returns: If the target type is a value: `operator Dst() const` => `impl Into<Dst> for &Src` If the target type is a reference: - `operator const Dst&() const` => `impl Into<CRef<'_, Dst>> for &Src` - `operator Dst&()` => `impl Into<CMut<'_, Dst>> for &mut Src` `const T()` maps the receiver to `&Src`, `T()` maps the receiver to `&mut Src`. PiperOrigin-RevId: 938696877

2026-06-25

Add support for std::atomic in Crubit. Note that std::atomic and std::atomic intentionally fall back to opaque bindings. Rust's standard library does not provide an AtomicCLong. Because long is 32-bit on Windows LLP64 and 64-bit on Linux LP64, hardcoding it to AtomicI64 or AtomicI32 would cause stack corruption across the FFI boundary. Consequently, std::atomic<size_t> will also become opaque on 64-bit Linux because Clang canonicalizes it to unsigned long. Users should prefer std::atomic<uintptr_t> or std::atomic<uint64_t> for cross-language atomics. PiperOrigin-RevId: 920404627

Undo Rust-side reconstruction of the FFI-passed nested IR to the database-managed IR. Unfortunately this caused some Crubit users to OOM during builds... PiperOrigin-RevId: 938020861

Undo Rust-side reconstruction of the FFI-passed nested IR to the database-managed IR. Unfortunately this caused some Crubit users to OOM during builds... PiperOrigin-RevId: 937997234

2026-06-24

Undo Rust-side reconstruction of the FFI-passed nested IR to the database-managed IR. Unfortunately this caused some Crubit users to OOM during builds... PiperOrigin-RevId: 937627303

Implement Rust-side reconstruction of the FFI-passed nested IR to the database-managed IR. Specifically, this change: - Implements `make_ir_from_tree` in `ir.rs` to reconstruct the declaration tree on the Rust side from `top_level_items`, and populate a lookup cache of itemId to items. - Ensures nested items are discoverable: `db::find_untyped_decl` looks up items in the reconstructed tree cache instead of `flat_ir.items`. - Propagates changes to IR structure and db to the relevant bindings generation logic ie. `generate_struct_and_union.rs` - Removes the `top_level_item_ids` field from the IR and other call-sites (except for the importer, which we avoid modifying to de-risk for regressions). Note that after further discussion, the (rest of this) restructure will be done atomically in this CL. The use_nested_ir flag has been deleted. PiperOrigin-RevId: 937556313

2026-06-23

Implement Rust-side reconstruction of the FFI-passed nested IR to the database-managed IR. Specifically, this change: - Implements `make_ir_from_tree` in `ir.rs` to reconstruct the declaration tree on the Rust side from `top_level_items`, and populate a lookup cache of itemId to items. - Ensures nested items are discoverable: `db::find_untyped_decl` looks up items in the reconstructed tree cache instead of `flat_ir.items`. - Propagates changes to IR structure and db to the relevant bindings generation logic ie. `generate_struct_and_union.rs` - Removes the `top_level_item_ids` field from the IR and other call-sites (except for the importer, which we avoid modifying to de-risk for regressions). Note that after further discussion, the (rest of this) restructure will be done atomically in this CL. The use_nested_ir flag has been deleted. PiperOrigin-RevId: 933733681

2026-06-22

Add support for std::atomic in Crubit. Note that std::atomic and std::atomic intentionally fall back to opaque bindings. Rust's standard library does not provide an AtomicCLong. Because long is 32-bit on Windows LLP64 and 64-bit on Linux LP64, hardcoding it to AtomicI64 or AtomicI32 would cause stack corruption across the FFI boundary. Consequently, std::atomic<size_t> will also become opaque on 64-bit Linux because Clang canonicalizes it to unsigned long. Users should prefer std::atomic<uintptr_t> or std::atomic<uint64_t> for cross-language atomics. PiperOrigin-RevId: 920404627

2026-06-18

Add support for C++ user-defined conversion operators. We map depending on the target type and pin/move characteristics: - Movable, locally-defined type (Record is Unpin and local to the crate): `operator Dst() const` => `impl From<&Src> for Dst` - Immovable, locally-defined type: `operator Dst() const` => `impl CtorNew<&Src> for Dst` - Foreign types, primitives, or reference returns: If the target type is a value: `operator Dst() const` => `impl Into<Dst> for &Src` If the target type is a reference: - `operator const Dst&() const` => `impl Into<CRef<'_, Dst>> for &Src` - `operator Dst&()` => `impl Into<CMut<'_, Dst>> for &mut Src` `const T()` maps the receiver to `&Src`, `T()` maps the receiver to `&mut Src`. PiperOrigin-RevId: 932645952

2026-06-17

Build and serialize the nested IR on the frontend. We restructure the IR so namespaces and records can contain other items. This has several consequences: * To support forward-declaring and break circular dependencies (Item -> Namespace/Record -> Item), `Item` is now a struct inheriting from `std::variant`. * Nested items are held via `std::shared_ptr` over `std::unique_ptr` to preserve copy constructors during this transition, and to maintain support for certain things like redeclarations. PiperOrigin-RevId: 933993865

2026-06-11

Support round-tripping to C++ and back for Rust types with lifetime parameters PiperOrigin-RevId: 930654647

2026-06-09

Fix generated code that fails to compile. Previously we would generate `delete ptr;` in the C++ glue code. This fails to compile when the delete operator isn't public (or is explicitly deleted). Add a check for such types that also have a destructor, and use the destructor instead creating code that compiles. PiperOrigin-RevId: 929160936

2026-06-08

Added support for users to re-export their namespace to their crate root PiperOrigin-RevId: 928818908

Add unstable_rust_features option to Crubit additional_rust_srcs This allows enabling unstable rustc features via an additional `#![feature(...)]` declaration at the crate root when compiling extra Rust sources attached to Crubit bindings. PiperOrigin-RevId: 928646453

2026-06-05

Wrap mutable fields in `Cell`. PiperOrigin-RevId: 927503898

2026-06-03

Add the `lifetime_inputs` field to proto messages and serialization logic. This field is currently ignored (b/454627672) but is expected by the backend. This CL also adds another field, `defining_target`, I had missed in the previous CL (translating IR to proto), which is used in the backend to search for unsupported items. PiperOrigin-RevId: 926305441

2026-05-28

Introduce a proto definition of the Clang-based IR and a feature flag gating its use. This change is made as part of an effort to move to a more compiler-agnostic IR format in place of our current JSON IR for the cpp-to-rust direction of Crubit. This will enable open-source users to use any version of Clang (or other compilers) and construct middleware to bridge this IR if they would like. The frontend and backend currently do not have the neccessary serialization/deserialization to construct and use the proto IR, hence we still default to the JSON IR (no-op change). PiperOrigin-RevId: 922909854

Replace `Environment` enum with an equivalent boolean flag. This enum was used to control whether source location information should be included in doc comments. This CL replaces the enum with a more direct boolean flag following the refactor (of the FFI call) to use protobufs, which demands an otherwise unused unspecified variant. PiperOrigin-RevId: 922738061

2026-05-26

Refactor `GenerateBindingsImpl()` to serialize the GenerateBindingsRequest/Response protos through the FFI boundary. PiperOrigin-RevId: 921680560

2026-05-19

Refactor `GenerateBindingsImpl()` to use Request/Response protobufs. The protos are passed as raw pointers and wrapped into a safe Rust object through the Rust Protobuf API. PiperOrigin-RevId: 915497206

2026-05-15

Define a protobuf model for `GenerateBindingsImpl()` This incremental change aims to provide a safer, layout-consistent format when passing C++-derived IR across the FFI boundary. PiperOrigin-RevId: 916034617

2026-05-04

Use renamed crates when checking for includes. Previously we would fail to find `--crate-header` for types in dependecies because we look them up without accounting for renames. For protos this means we look up `crate_proto` when our crate header is for `crate_rust_proto` and fail to find definitions. PiperOrigin-RevId: 910152011

2026-04-21

Fix protobuf bridging for nested messages. Crubit previously incorrectly assumed that the C++ generated class name for a protobuf (e.g. `MyMessage_Request`) perfectly matched the expected Rust type path (`my_message::Request`). This caused the `rs_bindings_from_cc` generator to fail to find the correct type from the Rust protobuf crate. This fix traverses the `DeclContext` in C++ to correctly reconstruct the nested `snake_case` Rust module paths, and uses this reconstructed `rust_name` in the generator instead of ignoring it. PiperOrigin-RevId: 903251309

2026-03-04

Initial setup of test matrix

This commit does not contain any .proto files.

2025-12-19

Eliminate TUSummary and use CFGSummary as the top-level summary unit. Required reworking the VirtualMethodIndexSummary interactions, but minimally, since the information needed by the CFGSummary should already be TU-independent. This will enable deduplication of CFGSummary objects for CFGs present in headers that are included by multiple TUs, which should be a significant performance improvement for multi-TU inference. PiperOrigin-RevId: 846741546

Instead of dropping inferable slots that cross a test boundary, tag and drop later Tag inferable slots as crossing a test boundary, as well as any evidence that is derived from such crossings. Only later do we drop the evidence. - This gives us an option to do some fall-back merging at the end. - It also avoids dropping inferable slots, which has a side-effect of not being able to pull in previous inference information when inferring with summaries. Also track the test boundary crossing in some summaries, when the later evidence collection doesn't involve the inferable slot summaries. PiperOrigin-RevId: 846722439

2025-12-02

Rename proto field for clarity. This evidence kind is only used if it is determined that the value is nullable, not in all cases. PiperOrigin-RevId: 839252173

2025-12-01

Second step in downrank/excluding test -> nontest evidence Tracks whether virtual method overrides are test/nontest in the "index" and use that information later to avoid propagation crossing test -> nontest from derived to base classes. After this, we can consider tracking the crossing in evidence (instead of filtering), and downranking during merge instead. PiperOrigin-RevId: 838876544

2025-11-20

Collect evidence for select templates of pointers from arg/param bindings. Matching the behavior of verification, these types are expected to have invariant nullability, though we only collect evidence for a single pointer type layer inside the template argument. PiperOrigin-RevId: 834909612

2025-11-02

Second step in downrank/excluding test -> nontest evidence Tracks whether virtual method overrides are test/nontest in the "index" and use that information later to avoid propagation crossing test -> nontest from derived to base classes. After this, we can consider tracking the crossing in evidence (instead of filtering), and downranking during merge instead. PiperOrigin-RevId: 816976917

2025-10-20

Hook up more of the inference with summaries -- first in infer_tu and tests This adds a TUSummary proto, to collect each of the individual summaries and the virtual method summary. For now, we keep the old infer_tu behavior as well (and parameterize the tests), but we can delete that once we've switched the default. PiperOrigin-RevId: 821652874 Change-Id: I4604c1cf1bd1f2c814b42016d4ad8207b6b65890

The documentation is generated from this commit.

2025-10-17

Retain propagated_from Evidence field in samples for computed SlotInferences. This will retain any future fields added to Evidence unless they are specifically cleared. PiperOrigin-RevId: 820684621 Change-Id: I6f2d4699e7b9ed54f39fe00ccb014e07624708cb

2025-10-16

Track the original symbol for which evidence was emitted when propagating to related virtual methods within a TU. PiperOrigin-RevId: 820225628 Change-Id: Ib1227eae3ccd37937945ced5cbc1434bb071d21e

2025-10-10

Add support for serializing VirtualMethodIndex to/from proto. This data needs to persist between inference stages. PiperOrigin-RevId: 817783981 Change-Id: Ic9dc537e6f5e7e6639338ecf1c6d98d5270b901a

Nullability inference: support overrides from previous inference iterations when processing summarized evidence. In the phase2 of inference, SummaryEvidenceCollector can check for overrides of nullability annotations for the given symbol. The nullability of a param is thus adjusted during inference, and the new nullability is used for subsequent evidence collection steps. The overlay only applies to "anonymous" declarations -- those that are not referenced by name and so not picked up in InferableSlots, nor modeled symbolically. PiperOrigin-RevId: 817767923 Change-Id: I2ef9b536689ea5d31ca07977bf5bdb741bf9ba44

Introduce function that summarizes the inference-relevant CFG portions and exports them in a protobuf. To avoid code duplication, we refactor SummarizerAndCollector into a templated class that abstracts over the backend "collector" class. The new function then reuses the summarization functionality, but exports the summaries in a protobuf, rather than processing them direclty. The existing functionality becomes a single standalone function which instantiates the template with the existing evidence collector class. This patch includes definition of new protobuf messages to represent the summaries. A basic selection of tests is added to verify the protobuf messages are created as expected. PiperOrigin-RevId: 817718410 Change-Id: I32b96843df6ab0d6118ace167cb310be985da968

2025-06-25

Treat overrides of ::testing::Test::SetUp as late initializers with similar semantics to constructors. Previously, the presence of any constructor leaving a smart pointer field default-initialized was enough for a nullable inference. Now, if any (there can currently be only one) late initializer initializes the field to something not-nullable, then we do not make that nullable inference. This allows inferences of nonnull for smart pointer fields that are only assigned a nonnull value in GoogleTest test fixtures' SetUp functions. These SetUp functions have long-standing, well-understood semantics that are not previously acknowledged by our analysis. The affected fields show up very frequently in codebases using GoogleTest, causing unnecessary Nullable annotations, but even more importantly, unnecessary conflicts. PiperOrigin-RevId: 775688004 Change-Id: I4ca17bd6659a57d0bec11def2cbe944f188fc747

2025-06-10

Migrate references/test uses of template alias annotations to use clang specifiers. PiperOrigin-RevId: 769721367 Change-Id: I06a766fd2227c66c0fa55b1ce675f03084b75251

2025-06-06

Internal change PiperOrigin-RevId: 768042619 Change-Id: I7f747a02f1130474a0011ea99ce0a450df63217e

2025-05-28

Add debugging information fields to SlotInference and SlotPartial to allow piping through and merging. PiperOrigin-RevId: 764265201 Change-Id: I2a36a51d28d84980706f713e03dc77f34957252e

2025-03-07

Infer Nonnull for pointers accessed with operator[]. PiperOrigin-RevId: 734675720 Change-Id: I1efa1e9dd2e5dbc7c7d6adbf4451d79699c40147