autocxx

autocxx copied to clipboard

There are some C++ types where autocxx just says "nope, we can't pass it by value" - autocxx calls these non-POD types; cxx calls them Opaque (see #17 for the terminology difference).

For those, autocxx offers no means to access the fields.

Rust cannot and should not attempt to access those fields, because we can't know the correct offsets. It's my intention that we should autogenerate accessor methods. Specifically, here's what I think we need to do.

1. For any non-POD type, when we discover the fields as output by bindgen, add a new type of AdditionalNeed to add an accessor method - https://github.com/google/autocxx/blob/main/engine/src/additional_cpp_generator.rs#L101. (Possibly we just want to do this for public fields or similar; I haven't checked if that information is exposed by bindgen or if it can be configured using bindgen options).
2. Generate a getter method with some plausible name within additional_cpp_generator.rs.
3. This will automatically be picked up during the second invocation of bindgen within autocxx, and therefore we'll get Rust bindings to this method within our ffi::cxxbridge generated code.
4. Now, make it work for fields which we can't safely pass by value because those fields themselves are non-POD types, e.g. std::string. One option here is to do a third pass of bindgen, which would replace fn thingy_getter(thingy: &Thingy) -> CxxString automatically with fn thingy_getter(thingy: &Thingy) -> UniquePtr<CxxString> and all would be well. But we don't really want to run bindgen three times... it's slow. So it would probably be better to add knowledge of these cases into additional_cpp_generator.rs itself.
5. Do setters as well.
6. Add syntactic sugar so it's less obvious that we're calling a method to get or set the field. I'm not sure how best to do this. #37 is in the area, as is #31.
7. Replicate this getting/setting syntax for POD types, where it will boil down to a direct field access in pure Rust, but with identical syntax.
8. Out of curiosity, see whether the generated assembly code is actually the same when cross-language LTO is used (see #52).

Step 4 probably shouldn't be tackled until after #58.