Skip to content

Adjust local variable names if param mappings conflict + other fixes#35

Merged
jamierocks merged 6 commits into
CadixDev:developfrom
DenWav:feature/lvt
Dec 31, 2020
Merged

Adjust local variable names if param mappings conflict + other fixes#35
jamierocks merged 6 commits into
CadixDev:developfrom
DenWav:feature/lvt

Conversation

@DenWav
Copy link
Copy Markdown
Contributor

@DenWav DenWav commented Dec 10, 2020

If a method parameter mapping exists which will conflict with an
existing local variable after remap, Mercury will now adjust that local
variable name by appending a number (starting from 1) to the name of the
local variable.

This commit attempts to fix local variables defined in the method itself
as well as any local variables defined in lambda expressions contained
by said methods.


I've pushed a couple more commits, one is a simple misc fix in AccessTransformerRewriter, and the other is another fix related to param mapping.


Okay I added another commit which fixes a quirk with inner class remapping.


And last commit fixes an issue with implicit imports of package-private inner classes of super classes.

@jamierocks jamierocks added the enhancement New feature or request label Dec 11, 2020
@jamierocks jamierocks added this to the 0.1.0-rc2 milestone Dec 11, 2020
If a method parameter mapping exists which will conflict with an
existing local variable after remap, Mercury will now adjust that local
variable name by appending a number (starting from 1) to the name of the
local variable.

This commit attempts to fix local variables defined in the method itself
as well as any local variables defined in lambda expressions contained
by said methods.
Param name mappings require resolving method mappings just as method
mappings do, which means to fully handle all cases we have to complete
the inheritance information in class mappings when we are trying to find
new mappings for method parameters.
@DenWav DenWav changed the title Adjust local variable names if param mappings conflict Adjust local variable names if param mappings conflict + other fixes Dec 13, 2020
Inner classes which aren't in the mappings was causing the import
context to incorrectly place unknown inner classes in the obfuscated
outer class's FQN rather than the deobfuscated name. Using
`computeClassMapping` fixes this automatically.
There were 2 issues here. First, the conditional was inverted, so
classes which _were_ in the same package were getting skipped, rather
than the other way around. Then the second issue was the package names
weren't normalized to the same format.
While this can be helpful for incomplete mappings, for complete mappings
it doesn't help, and the option to disable it can help.
Copy link
Copy Markdown
Member

@jamierocks jamierocks left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Imports aside, all looks good.

@jamierocks jamierocks merged commit 17a90e0 into CadixDev:develop Dec 31, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

enhancement New feature or request

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants