Feature/auto hierarchy - #12
Open
yungselm wants to merge 30 commits into
Open
Conversation
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.
…passes prewritten tests
This comment was marked as duplicate.
This comment was marked as duplicate.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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:
vtkNew caused dangling pointers, so all C++ wrappers now use raw T* with T::New() / sself->Delete()
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.