Rust SIG Meeting - 2026-03-31 #21

PLeVasseur · 2026-03-31T13:46:17Z

PLeVasseur
Mar 31, 2026
Collaborator

Hey folks 👋 welcome to our 6th meeting of 2026.

Rust SIG Meeting 2026-03-31

Agenda

Solicitation of notetaker
- Pete LeVasseur
Rust Watercooler Chat Topic - A Rant about C++ <=> Rust Interop; Markus Hosch - BMW
Review GitHub repo content and discuss how to enrich (Pete)
1. Issues
2. Discussions are now active! We'll take meeting notes here based on previous agreement in the SIG.
Office hours - Rust + Automotive questions - come chat! (All)
Discuss upcoming events / news related to Rust & Automotive (All)
Meeting close

Check-in area

(around ~15 folks total max at one point)

Housekeeping section, please add

Document space: https://drive.google.com/drive/folders/1Ub0qTLKvTFilPC9TFVEdTyWn_9qJ-vYD?usp=drive_link
GitHub repo: https://github.com/rust-sig/rust-sig
Eclipse SDV Slack channel: #rust-sig

Tasks

Meeting Minutes

A Rant about C++ <=> Rust Interop; Markus Hosch - BMW

Markus works on the Eclipse S-CORE communications library; complex and large C++ codebase

Great new language to prevent common issues
Management obviously doesn't want to spend the time and money to rewrite everything in Rust
Need to bring interoperability story of piece by piece migration

Spoiler: Rust <=> C++ interop is only so-so

Only has C ABI in Rust for a specific platform
Because developers took a lot of care to make Rust as platform aware as possible for ABI
Almost everything is there that's needed to translate what's written in C to Rust

Maybe obvious or not but C++ and Rust approach things differently

C++ has a term for something called a destructive copy; takes contents and keeps it alive
Rust does a bitwise copy and forgets about the old copy
In C++ move constructor and move operator
- Should only move, but often they do other things

Rust <=> C++ Generics

There are ways to sneak around this
But still are gaps due to having to ultimately reach for C ABI

Brief list of tools that are there to help ease the integration of C++ and Rust:

???: Missed the name of this tool

cxx

cxx: done by dtolnay
- Does a lot in the Rust ecosystem
- His library crates often use Rust procedural macros
  - cxx is no exception

How to use cxx on Rust side:

prefix module (mod) with certain macro: #[cxx::bridge]
can specify that something is opaqe, e.g. OpaqueInt
declare functions that you want to use from Rust
- #[cxx_name = "ExecuteCppFunction]
- fn
Several checks are done by cxx if you annotate this correctly
Not exhaustive; still unsafe ultimately

On C++ side:

listed here not as opaque here
instead we make use of the UniquePtrResult type alias to a yourcompany::Result<std::unique_ptr<OpaqueInt>>
limitations at time if you're having to use the heap; memory fragmentation is real

Templates?

Note super well supported generally
Certain special types are well supported like std::unique_ptr<T> and std::vector<T> this is supported
If you have a special type that you use, that is custom you need to do that's done like std::string is done over top of std::basic_string<T>
- e.g. type MyConcreteType = Templated<i32>;

Getting into details on cxx bridge

On Rust side procedural macro generates a bunch of code to generate a C thunk function per type, e.g.
- impl UniquePtr<OpaqueInt> { /* .. *. / }
Issue is that the C ABI doesn't have this concept of template, so you end up having cxx encode this into the type only for special types
You otherwise need to do this yourself
On the C++ side there's a specific tool from cxx that's used to generate the C++ bits needed for the bridge
- when using Bazel like is done in Eclipse S-CORE they call the cxx tool to do this work as they do not use cargo underlying Bazel

Still some trade-offs, even using cxx

Need to fully declare types that go between worlds as fully defined types
Or bite the bitter apple through the std::unique_ptr<t> indirection
- Not too bad often; do this work at program initialization
- Then have references at runtime and the references are often fast enough
- For hot-paths not be appropriate as often then having to call into C++ and paying performance penalties

Arena/custom allocators?

With std::unique_ptr<T> can have custom deleters that know how to reclaim resources rather than a plain delete()
Created a PR three years ago to add this to cxx
- Explains why cxx looks good at first
- But ultimately the maintainer dtolnay closed the PR as it seemed to not work well with cxx as it's an opinionated library
Seemed reasonable, but there are some complications
- deleter is 2nd memberon macOS, 1st member on std::unique_ptr<T>
- currently not a clean way to do this on cxx
- added tests to ensure this is clear and tested

Did you end up forking to get this capability of arene/custom allocators?

dtolnay gave some suggestions to work around it
- one of the suggestions: hand-roll at a lower level at cbindgen/bindgen
if needed ultimately would have to fork it; maintenance burden
to make safety-case still need to integrate at cxx really
C ABI makes things kinda hard; maybe C API and then have Rust closures that implements this as a wrapper
- one of the other suggestions from dtolnay
- a lot of how cxx works; seems workable in principle
std::vector<T> supports custom allocators, but also not supported in cxx

autocxx

Tried autocxx once; via Google

it generates what you would get from hand-rolling via cxx
ultimately did this using AI kinds of tools to do this sort of boilerplate to get what's needed
from what we can tell support from Google has kinda tapered off

crubit

Seems quite complete; via Google

Goole has made clear that it's not currently usable outside of Google
checked yesterday and didn't see its status changed
built on top

bindgen

Useful for C

Not super clear what would be supported for C++
More lightweight stuff works okay; more complex things seems less so
If you have simple APIs, light weight templates it might make sense to use

zngur

Relatively more new

Relies on using an IDL (Interface Definition Language)
- define what goes across the boundary
- similar to SWIG in the past
Seems more helpful for exposing Rust crates to C++
Adobe seems to be interested in its usage

WebAssembly Interface Types (WIT)

Often it's done to have no memory sharing between WebAssembly Modules (wasm)

But there's an approach that's been taken to remove that memory-safety to instead implement this to allow for more performance
- https://github.com/cpetig/wit-bindgen/blob/work-in-progress/tests/runtime-async/async/future-string/test.cpp
Helps with still understanding which side has the error
Source is identical; the only difference is how you build it
Able to easily grab memory from C++ from Rust, but not vice-versa

Overall

Currently Eclipse S-CORE has chosen cxx

Challenges

Cannot really at times explain the move-ability semantics from C++ in Rust

Guiding development of communications framework in Eclipse S-CORE

kind of a pipes and filters architecture common in automotive
using C++17; so have to reimplement std::expected<T, E> on top of std::variant
TrivialCopyable concept from C++ comes into focus when considering bridging
- libcpp in Rust to bring certain well-known types from C++
  - libcpp_derive: C++ type use their Result type which uses std::variant
  - string_view: required for logging
dependence on which version o
- libstdc++ 1st comes
- cxx: 2nd comes
had to put stdlib ABI guard: #[cfc(xx = libcxx_layout)]
at runtime at startup need to call once to get the identifier for interpretation of types on both sides of C++/Rust
- helps with knowing how to take slices or interacting in lossy ways
#[libcpp_derive::import] listed on types to generate the necessary boilerplates for them
- important for pointer types which are bitwise-copyable, so long as you forget about the old instance
- seems beneficial for the Rust community to have as a community library
- condense all the knowledge in a way to be sure on what's sound and unsound