Skip to content

Feature/auto hierarchy - #12

Open
yungselm wants to merge 30 commits into
jonaspleyer:mainfrom
yungselm:feature/auto-hierarchy
Open

Feature/auto hierarchy#12
yungselm wants to merge 30 commits into
jonaspleyer:mainfrom
yungselm:feature/auto-hierarchy

Conversation

@yungselm

@yungselm yungselm commented May 29, 2026

Copy link
Copy Markdown

Hi Jonas
First of all congratulations on how much work you already put in! It still quite the intimidating project to me due to its complexity.
I already opened the pull request but it will probably need some rounds of reviewing. I think I understand the concept of the crate more or less, but of course I couldn't understand in detail the full source code yet, so I hope I'm not completely off with this.

I started by writing tests to make the expected behaviour as clear as possible (and keeping the tests simple and readable), then implemented the inheritance hierarchy generation following the structure you suggested. Everything else that followed was basically just solving problems that showed up when trying to compile and run examples/sphere_source.rs after the tests passed:

  • Had to handle Rust keywords as method names first (type, ref, self, ...)
  • Numeric primitive pointer types were not bridgeable and had to be bailed on
  • C++ pointers were an absolute pain (!) now bails on everything except Pointer::Ref and Pointer::Star, including removing a dead StarStar special-case that was never reachable in the actual XML anyway
    vtkNew caused dangling pointers, so all C++ wrappers now use raw T* with T::New() / sself->Delete()
  • The hardcoded vtktoken caused linker errors on my setup (VTK 9.1), so I removed it
  • C doesn't support overloading, so duplicates are now deduplicated keeping only the first overload

I also fixed a few bugs I noticed along the way (details in the CHANGELOG): a c_longlong /c_uchar type mapping error, a panic in get_exposable_methods when a parent class has no scanned XML, and the generated create/drop tests which broke after the vtkNew switch.

It's an extensive PR, but I made sure to leave lots of comments and added a very detailed CHANGELOG (AI doublechecked). I wait for your return from the holidays.

One thought for what could come next: would automatic trait derivation make sense here, e.g. generating #[derive(Debug)] for the struct bindings (I realized when trying to print the generated sphere_source)? Or would cross-module supertrait bounds be the more pressing thing to tackle first (didn't know how to handle)?

PS: It's overly bloated because I reincluded the setup_vtk.sh script and the regenerated vtk-rs-9.1 files. Tell me if I should exclude these files.

yungselm added 30 commits March 8, 2026 15:37
IRMethod now stores both the full snake_case binding name (used as the
extern "C" symbol) and the original PascalCase VTK method name (needed
to generate the C++ call sself->SetRadius(...)). The short_name() helper
strips the class prefix for use in trait method signatures.
@yungselm

This comment was marked as duplicate.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant