Proto commits in google/crubit

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

2026-10-01

Honor `ABSL_POINTERS_DEFAULT_NONNULL` in rs_bindings_from_cc. Registers the nullability `#pragma nullability file_default` handler and uses the recorded file defaults when a pointer type has no explicit nullability annotation. The governing file is the file containing the decl being imported, or, for types spelled via a typedef, the file containing the innermost typedef. This mirrors `getGoverningFile` in the nullability library. A `nonnull` file default is treated just like an explicit `_Nonnull`: it sets `CcType::is_nonnull`, and `PointerTypeKind::NON_NULL` for raw pointers. Codegen still only acts on it for smart pointers in targets with the `nonnull_smart_pointers` feature. Substituted template arguments (e.g. `std::vector<std::unique_ptr<T>>`) are not yet handled. PiperOrigin-RevId: 991887464

2026-09-30

Carry nullability on template arguments into the Rust bindings. `std::vector<absl_nonnull std::unique_ptr<T>>` now becomes `cc_std::std::vector<cc_std::std::NonNull<cc_std::std::unique_ptr<T>>>` (under the `nonnull_smart_pointers` feature), and the same holds for bridged types, e.g. `absl::StatusOr<absl_nonnull std::unique_ptr<T>>`. The specialization decl is shared by every use with the same canonical arguments, so it cannot carry per-use information like nullability. The importer already recorded the as-written template argument on the use site's `CcType`, but only if it carried an explicit lifetime. It now records it regardless: * The single-argument restriction stays: consumers of `template_args` still assume one argument. Defaulted arguments are not written, so e.g. `std::vector<T>` still has one. * Nothing is recorded if the argument fails to convert (except that an argument carrying an explicit lifetime still reports its error, as before). * The bridge arity check now falls back to the canonical argument per position, since one written argument can be shorter than the bridge's canonical argument list. `std::shared_ptr` now uses `choose_one_type` like the other smart pointers. * When looking through a system-header typedef, the typedef's file now governs the nullability default of the types inside it. As-written arguments keep typedef sugar, so `std::atomic` now looks through aliases when choosing the Rust atomic type. PiperOrigin-RevId: 991090487

Honor ABSL_POINTERS_DEFAULT_NONNULL in rs_bindings_from_cc. Registers the nullability `#pragma nullability file_default` handler and uses the recorded file defaults when a pointer type has no explicit nullability annotation. The governing file is the file containing the decl being imported, or, for types spelled via a typedef, the file containing the innermost typedef. This mirrors `getGoverningFile` in the nullability library. A `nonnull` file default is treated just like an explicit `_Nonnull`: it sets `CcType::is_nonnull`, and `PointerTypeKind::NON_NULL` for raw pointers. Codegen still only acts on it for smart pointers in targets with the `nonnull_smart_pointers` feature. Substituted template arguments (e.g. `std::vector<std::unique_ptr<T>>`) are not yet handled. PiperOrigin-RevId: 988296364

Record as-written template arguments that carry lifetimes Clang creates one `ClassTemplateSpecializationDecl` per *canonical* template argument list, so `W<int* $a>` and `W<int* $b>` denote the same record, and the importer produced byte-identical IR for the two. The sugar that carries the lifetime survives only on the use-site `TemplateSpecializationType`, and `Importer::ConvertTemplateSpecializationType` never consulted `type.template_arguments()`: both of its exits went straight to `ConvertTypeDecl`, which returns a bare `ItemId`. Record the as-written arguments on the `CcType` for that one use, in the `template_args` slot that `CcTypeVariant::Decl` already has and that `lifetime_defaults_transform` already populates from the Rust side. Like `is_const`, this describes one use of the type rather than the type itself. `lifetime_defaults_transform` used to overwrite `template_args` with the element type of the shared specialization decl, discarding the lifetime for exactly the types that consume `template_args` (`std::vector`, `std::unique_ptr`, `absl::Span`, `c9::Co`). It now starts from the as-written argument when the importer recorded one, and falls back to the decl's argument otherwise. PiperOrigin-RevId: 990615094

2026-09-29

Record `_Nonnull` on raw pointers in the rs_bindings_from_cc IR. A raw pointer annotated `_Nonnull` (e.g. via `absl_nonnull`) now gets `PointerTypeKind::NON_NULL` instead of `NULLABLE`. No change to generated bindings: both kinds still map to a Rust raw pointer. This only makes the information available to codegen. PiperOrigin-RevId: 990532093

2026-09-24

Prepare `rs_bindings_from_cc` for round-tripping Rust stdlib types (`core`/`alloc`/`std`). When C++ code embeds or passes by value C++ bindings of Rust standard library types (such as `rs::std::string::String`, `rs::std::path::PathBuf`, or `rs::std::fs::File`), `rs_bindings_from_cc` needs several fixes before the Bazel rules mark `rs_core`/`rs_alloc`/`rs_std` headers as having bindings: 1. Conditionally emit `extern crate alloc;` in the generated `_rust_api.rs` when the target depends on `//third_party/crubit/support/rs_std:rs_alloc` (directly or transitively via `:rs_std`), since `rustc` does not place `alloc` into the extern prelude automatically. 2. Record `is_trivially_copyable` on `ExistingRustType` in the IR so that `RsTypeKind::implements_copy()` returns `false` for non-`Copy` Rust types (wrapping struct fields in `ManuallyDrop<T>` and avoiding invalid `T: Copy` static assertions). 3. Relocate non-trivially-copyable `ExistingRustType` by-value function parameters via `ManuallyDrop` on the Rust side and `crubit::Slot<T>::AssumeInitAndTakeValue()` in the C++ thunk so types without `Default` (e.g. `std::fs::File`, where `File(File&&) = delete` in C++) can be passed by value using their `UnsafeRelocateTag` constructor. 4. Set `policy.FullyQualifiedName = true` in `ExistingRustTypeImporter` so `using` aliases inside namespaces (such as `rs::std::string::String`) retain their enclosing namespace qualification in generated C++ thunks. PiperOrigin-RevId: 987707583

Record as-written template arguments that carry lifetimes Clang creates one `ClassTemplateSpecializationDecl` per *canonical* template argument list, so `W<int* $a>` and `W<int* $b>` denote the same record, and the importer produced byte-identical IR for the two. The sugar that carries the lifetime survives only on the use-site `TemplateSpecializationType`, and `Importer::ConvertTemplateSpecializationType` never consulted `type.template_arguments()`: both of its exits went straight to `ConvertTypeDecl`, which returns a bare `ItemId`. Record the as-written arguments on the `CcType` for that one use, in the `template_args` slot that `CcTypeVariant::Decl` already has and that `lifetime_defaults_transform` already populates from the Rust side. Like `is_const`, this describes one use of the type rather than the type itself. PiperOrigin-RevId: 987065061

2026-09-23

Rename `is_trivial_abi` to `is_rust_movable` in the IR. The field says whether Rust may move a value with `memcpy`, without running the C++ destructor on the old location. The old name pointed at `[[clang::trivial_abi]]` and at the ABI. The attribute is related, but it is only one of the ways a record gets this property, and the property itself says nothing about how a value is passed to or returned from a function. This CL only renames the field and adjusts the related names and comments. There is no behavior change: * `Record::is_unpin` no longer claims that this property is called "trivially relocatable" in C++. No published C++ standard defines that term, and the competing proposals disagree on what it should mean. * The `ir.proto` rename TODO is now done, so it is removed. * The `IsRustMovable` matcher comment in `importer_test.cc` said "trivial for calls", which describes an ABI property rather than this one. PiperOrigin-RevId: 986990737

2026-09-22

No public description PiperOrigin-RevId: 985651355

2026-09-21

Make `is_trivial_abi` independent of the target's C++ ABI. Crubit clients such as Chromium build the same Rust code for several target platforms, so the shape of the generated bindings should not depend on the target. `is_trivial_abi` controls the shape of some generated bindings - e.g. whether a C++ record is passed as `&mut T` rather than `Pin<&mut T>`. The "Unpin for C++ Types" design doc defines the underlying property as being "trivial for calls" in Clang: either actually trivial, or made trivial for calls with `[[clang::trivial_abi]]`. Before this CL, the importer did not ask that question - instead it asked `clang::CXXRecordDecl::canPassInRegisters()`, which is only a proxy for the desired property. In particular `canPassInRegisters` is exact on the Itanium C++ ABI, but not on the Microsoft C++ ABI (see [`canPassInRegisters` in `clang/lib/Sema/SemaDeclCXX.cpp`](https://github.com/llvm/llvm-project/blob/5dfe8605911e3f0f43fe2b5c08b4ffc23f2af37a/clang/lib/Sema/SemaDeclCXX.cpp#L6982)): * A small class with a trivial copy constructor can be passed in registers even when it has a non-trivial destructor, so `struct S { ~S() {} };` was `Unpin` only when targeting Windows. * The move constructor is ignored, so a class with a trivial copy constructor and a user-provided move constructor was `Unpin` only when targeting Windows. * A non-deleted copy constructor is required, so a move-only class with a trivial move constructor was `Unpin` only when targeting Linux. After this CL, the desired property is calculated more directly, in a new `IsRustMovable` helper function. The helper mirrors the Itanium C++ ABI branch of `canPassInRegisters`, so the result no longer depends on the target's C++ ABI, and it is unchanged on every currently supported target platform. One source of target dependence remains: Clang drops `[[clang::trivial_abi]]` when a base class or a field cannot be passed in registers on the target ABI. See b/564616479 and the `TrivialAbiWithMoveOnlyField` test case. PiperOrigin-RevId: 981314297

2026-09-18

Add layout-compatible std::optional<T> bindings. Today, user's rely on `std::optional<T>` bridging to `Option<T>` in Rust, and do not rely on it directly in non-bridge positions because Crubit makes those a blob of bytes. This change does two things: 1. Unconditionally turns those blobs of bytes into either `optional<T>` or `trivial_optional<T>`, depending on `Copy` requirements. This is a purely additive change and cannot realistically break anyone. 2. Add a flag to conditionally disable composable bridging `std::optional<T>` and instead use this new layout compatible `optional<T>`/`trivial_optional<T>` instead. This is a breaking change, and therefore is behind a flag to users can opt in when they're ready. PiperOrigin-RevId: 983911647

Add layout-compatible std::optional<T> bindings. Today, user's rely on `std::optional<T>` bridging to `Option<T>` in Rust, and do not rely on it directly in non-bridge positions because Crubit makes those a blob of bytes. This change does two things: 1. Unconditionally turns those blobs of bytes into either `optional<T>` or `trivial_optional<T>`, depending on `Copy` requirements. This is a purely additive change and cannot realistically break anyone. 2. Add a flag to conditionally disable composable bridging `std::optional<T>` and instead use this new layout compatible `optional<T>`/`trivial_optional<T>` instead. This is a breaking change, and therefore is behind a flag to users can opt in when they're ready. PiperOrigin-RevId: 981299096

2026-09-17

Add label hint support and auto-inference for CRUBIT_INTERNAL_RUST_TYPE PiperOrigin-RevId: 983136933

Add label hint support and auto-inference for CRUBIT_INTERNAL_RUST_TYPE PiperOrigin-RevId: 981709954

2026-09-16

Add label hint support and auto-inference for CRUBIT_INTERNAL_RUST_TYPE PiperOrigin-RevId: 981709954

2026-09-15

Add opt-in layout-compatible `std::optional<T>` bindings. `std::optional<T>` is bridged by value to a Rust `Option<T>`, so it cannot be used anywhere that requires a layout-compatible type: struct fields, pointees, or as a template argument to another vocabulary type. `std::optional<T>` is in fact layout-compatible (libc++ and libstdc++ both store the payload inline followed by an engaged flag), so bridging is not required, only convenient. Add a `layout_compat_optional` feature, mirroring `layout_compat_string`. A target which enables it gets a layout-compatible Rust type everywhere instead of the bridged `Option<T>`, and so can use `std::optional<T>` in all of the positions listed above. The default remains bridging, so existing callers are unaffected and can migrate incrementally. `std::optional<T>` is now imported both as a `BridgeType::StdOptional` and as a `TemplateSpecialization::StdOptional`; the generator selects between them based on the feature. The layout-compatible path reuses the existing `UniformReprTemplateType` machinery that backs `std::vector<T>` and `std::shared_ptr<T>`. The Rust type stores `T` inline, so element types which are not `Unpin` are rejected for now with a dedicated error. Storing `T` inline requires a `MaybeUninit` payload and therefore a manual `Drop` impl, and Rust forbids implementing both `Copy` and `Drop`. A single type would consequently never be `Copy`, not even for `std::optional<int>`, which is trivially copyable in C++. Ship two types instead, following the existing `unique_ptr` / `virtual_unique_ptr` precedent of two Rust types for one C++ type: * `cc_std::std::trivial_optional<T>`, for `Copy` `T`. This has no destructor and is itself `Copy`. * `cc_std::std::optional<T>`, for everything else. This has a `Drop` impl which destroys the engaged value, and is `Clone` but not `Copy`. Both are layout-compatible with `std::optional<T>` and expose the same API, and Crubit selects between them based on the element type. A record containing a `std::optional<T>` field therefore keeps deriving `Copy` exactly when the corresponding C++ type is trivially copyable. PiperOrigin-RevId: 981299096

2026-09-14

rs_bindings_from_cc: Honor _Nonnull annotations on unique_ptr and shared_ptr A C++ API that declares `_Nonnull std::unique_ptr<T>` is promising its callers something that Rust can express in the type system, but Crubit was discarding it: the generated signature was the same `unique_ptr<T>` you get for an unannotated parameter, so Rust callers had to check for null anyway. Annotated smart pointers now generate `NonNull<unique_ptr<T>>` (or `NonNull<virtual_unique_ptr<T>>` / `NonNull<shared_ptr<T>>`), which derefs straight through to `T`. How it works: * `Importer::ConvertType` reads `Type::getNullability()` and records it on `CcType` as `is_nonnull`. Nullability describes one *use* of a type like a cv qualifier, rather than the declaration being referred to, so it belongs on `CcType` and not on the record that carries the `unique_ptr`-ness. It has to be read in `ConvertType` specifically: nullability is sugar, and `ConvertUnattributedType` looks through the `AttributedType` that carries it. * `rs_type_kind` then wraps the two smart-pointer `UniformReprTemplateType`s when the bit is set. `NonNull` is `#[repr(transparent)]`, so this needs no layout, ABI, or thunk changes. The bit is recorded for every type that can carry the annotation, but only smart pointers act on it. `_Nonnull` on raw pointers, `std::function`, and the other class types Clang accepts it on stays ignored, which is today's behavior. Rollout is behind a new `nonnull_smart_pointers` feature, off by default and excluded from the `all` feature set. `absl_nonnull std::unique_ptr<...>` is already widespread, so honoring it unconditionally would change the generated signature of many existing targets at once, and callers could start depending on the new signatures before anyone noticed. Opting in per target keeps the blast radius at zero. Followup work is required to make cc_bindings_from_rs map `cpp_std::NonNull<Ptr>` types back into `_Nonnull` in C++. PiperOrigin-RevId: 981243342

2026-09-08

Add `CRUBIT_PUB_CRATE` annotation to restrict C++ function and method bindings to `pub(crate)` visibility in Rust. This allows C++ helper functions and internal methods to be called from custom Rust source files (`srcs`) in `rust_api_from_cpp` without exposing them in the public Rust API. PiperOrigin-RevId: 978185571

2026-09-02

Support Rust Protobuf message fields, references, and pointers in cc_bindings_from_rs. - Add proto::Rust<T> (proto2::Rust<T>) in support/protobuf/rust.h as a non-nullable, movable C++ smart pointer layout-compatible with Rust-owned Protobuf message handles. - Support Protobuf message fields in structs via proto::Rust<CppProto>. - Support Protobuf message references (&Proto), raw pointers (*const Proto), and generic containers (Vec<T>, NewStatusOr<T>) in layout-compatible positions. PiperOrigin-RevId: 974760036

Reorganize unique_ptr API to encourage Box conversion PiperOrigin-RevId: 936971083

Internal change. PiperOrigin-RevId: 975298756

Enable portable_abi_compatible for crubit. PiperOrigin-RevId: 971934605

Internal-only change. PiperOrigin-RevId: 974979014

Fixes for template instantiation. This change, without loss of generality wrt *Mut variants: - Stops trying to generate std::ops::Index implementations for CRef returns (which is impossible) and CcIndex returns (which we may want to revisit) - Fixes a problem with !Unpin types and thunks for CcIndexMut - Does not generate CcIndex implementations when the return type would have an unbound lifetime. PiperOrigin-RevId: 970913058

2026-09-01

Add user defined generics case to TemplateSpecializations. PiperOrigin-RevId: 974768423

Make proto::Rust<T> non-movable in C++ to preserve non-null invariant. - Delete move constructor and move assignment from proto::Rust<T> (proto2::Rust<T>) in support/protobuf/rust.h. - Remove NewStatusOr<Proto> from cc_bindings_from_rs protobuf test since non-movable types cannot be returned by value from C++ wrapper functions. PiperOrigin-RevId: 974770314

Create single crate crubit_support that holds all our Rust support libs. In OSS it's easy to forget to include rust support libraries because they each have to be manually published to crates.io and threaded through cargo-cpp_api_from_rust. To ease this create one unified crate that we can upload and depend on. Now whenever we want to add a support lib we only have to re-upload the crate without any of the threading. This also fixes an incidental issue with uploading crates by moving the Cargo.toml to be adjacent with the Rust source code. PiperOrigin-RevId: 973886171

Emit self-referential constants as functions. Rust inherent constants that reference their Self type were emitted as C++ static constexpr's that also referenced their self type. This causes a compilation error because a C++ class type is not available when a static constexpr is evaluated, causing errors around incomplete types. We break this by emitting self-referential constants as constexpr functions. This allows for keeping them as constexpr (vs supressing the bindings or making them static consts). PiperOrigin-RevId: 974142978

Support Rust Protobuf message fields, references, and pointers in cc_bindings_from_rs. - Add proto::Rust<T> (proto2::Rust<T>) in support/protobuf/rust.h as a non-nullable, movable C++ smart pointer layout-compatible with Rust-owned Protobuf message handles. - Support Protobuf message fields in structs via proto::Rust<CppProto>. - Support Protobuf message references (&Proto), raw pointers (*const Proto), and generic containers (Vec<T>, NewStatusOr<T>) in layout-compatible positions. PiperOrigin-RevId: 972734189

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