| commit | 190b90aa079cdce830d16fa5d5ffa1c7db21a748 | [log] [tgz] |
|---|---|---|
| author | Devin Jeanpierre <jeanpierreda@google.com> | Tue May 24 06:00:34 2022 -0700 |
| committer | Copybara-Service <copybara-worker@google.com> | Tue May 24 06:01:10 2022 -0700 |
| tree | 3f1b65eae0340ed539cacaaba905c4b5b5e47592 | |
| parent | 3bd8b7c704daf5c9ff1b700625754b24b591ae32 [diff] |
Support unions in `#[recursively_pinned]`, albeit without supporting pin-projection.
The rationale for why unions don't receive a `pin_project` function is documented here -- tl;dr we can't project because we can't know which field is active.
Users can just do it by hand, if they do know which field is active. Alternatively, we can add -- and this is still open even for structs -- we can add field-specific accessors, like `union U { x: i32, y: i64}` could have `project_x()` and `project_y()` functions.
The rationale for why we *should* support unions isn't documented, it's somewhat taken as a given, right? But like -- when this was originally written, I don't think I fully appreciated that this would be applied to literally every C++ type. And some features will apply to some types, and others to other types. For another example, I will be adding *pointer* projection in a followup CL, and that *will* support unions (but won't support enums!) The only type that's going to have every single subfeature supported is likely going to be structs. :)
PiperOrigin-RevId: 450662659
Extremely experimental interop tooling for C++ and Rust.
Please don‘t use, this is an experiment and we don’t yet know where will it take us. There will be breaking changes without warning. Unfortunately, we can't take contributions at this point.
$ apt install clang lld bazel $ git clone git@github.com:google/crubit.git $ cd crubit $ bazel build --linkopt=-fuse-ld=/usr/bin/ld.lld //rs_bindings_from_cc:rs_bindings_from_cc_impl