Support explicit vtable size definition in data.yml - #1982
Merged
Merged
Conversation
Fixes some renaming issues.
wolfcomp
force-pushed
the
data-explicit-vtable-size
branch
from
October 4, 2026 15:46
6830355 to
7748483
Compare
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
1 participant
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.
There are two reasons vtable renaming throws errors - either a vtable has no xrefs and thus the size overshoots the true size, or a function in the vtable has a direct xref and the size undershoots the true size. While it is possible to fix the first case by declaring the missing vtables, the second case is more annoying. Supporting an explicit size lets us just fix it the easy way.
Note that in the changes the second case only applies to Client::UI::RaptureAtkModule::InventoryCache.
Might be better to add the missing vtables for the EventHandler child cases so the sizes dont have to be updated whenever the base classes grow however those vtables will probably fail to match in future versions due to the lack of xrefs and have to be manually updated anyway...
With these changes the only errors on idarename import are where IDA has renamed functions incorrectly itself.