Enhancing VTable Generation to Support Inherited Classes
Input C/C++ Header
class IUnknown {
public:
virtual void Release() {
delete this;
};
};
class iTH : public IUnknown {
public:
virtual void AccessibleFunction() = 0;
};
class CTH: public iTH {
public:
CTH() = default;
void AccessibleFunction() override {};
};
iTH *CreateITH() {
return (iTH *)(new CTH());
}
int main() {
iTH *ptr = CreateITH();
ptr->AccessibleFunction();
ptr->Release();
return 0;
}
Bindgen Invocation
bindgen::Builder::default()
.header("input.h")
.vtable_generation(true)
.generate()
.unwrap()
Actual Results
Currently, the vtable generation is limited to virtual classes without any base members.
Expected Results
The expectation is to extend vtable generation to support more complex class hierarchies.
Current Work Status
I'm in the process of addressing this issue through a PR. My aim is to remove the limitation preventing the generation from working with classes that have inheritance. However, I've encountered some hurdles along the way. It would be immensely helpful to connect with a maintainer of rust-bindgen to discuss the underlying architecture in more detail.
So far, I've made progress, but I've hit a roadblock. Specifically, I'm unsure how to access the comp_info of base members in order to retrieve their associated fields, types, and sizes. My goal is to associate a VTable declaration for each class with accurate information. Additionally, I aim to incorporate base member fields directly into each class, rather than adding base_XXX fields to each class (which occurs due to vtable merging).
In general this seems like a feature worth implementing.
Specifically, I'm unsure how to access the comp_info of base members in order to retrieve their associated fields, types, and sizes.
Does something like:
let base_ty = ctx.resolve_item(base.ty).expect_type();
not work? From there you have the type (you could have an as_comp or so to get the compinfo). Depending on what you want to do with type aliases etc you might want to do something like base.ty.into_resolver().through_type_refs().resolve(ctx).expect_type();, but I might be missing something?