Inefficiency and random unexpected exclusions in Renamer
ItzSomebody opened this issue · 1 comments
From convo on discord (huge thanks to @MrExplode for spotting!): https://canary.discord.com/channels/495471385351553024/495481816128421899/831649568336117780
The current renamer design (both radon 2 and 3) attempts to check all subclasses of a parent class for inheritance via className + '.' + methodName + methodDesc
. Radon achieves this through recursion and has a nicety of being easy to understand. Unfortunately, what this does is search potentially unrelated classes -- in fact, the entire inheritance graph is traversed. Since I am on Windows (disgusting) at the moment, here is a visual aid I whipped up in mspaint.exe:
With the current algorithm, all classes in this graph will be traversed when checking inheritance for some virtual method in MyParentClass. This is very likely the cause of the random reports given to me about methods being excluded by renaming unintentionally.
Also, since this requires a little bit of rethinking of the renamer, perhaps this would be a good time to
-
Fix remapping for a specific annoying case of lambdas (see: https://github.com/videogame-hacker/oof-jvm/tree/master/src/anonymous_lambda) and
-
Add the much requested feature of remapping hardcoded reflections/methodhandles