There are still some more contexts we can do this in - unary/binary
expressions and invocation contexts. I think Fernflower might handle the
former, but it doesn't handle the latter. Unfortunately, JavaParser's
method resolution code is still a bit too buggy to do the latter at the
moment.
Signed-off-by: Graham <gpe@openrs2.dev>
The BinaryExprTransformer deals with this to an extent. However, it
requires multiple passes to do so. Adding support to AddSubTransformer
allows it to be done in a single pass.
Signed-off-by: Graham <gpe@openrs2.dev>
It'd be nice if we could make it run a single pass (and there are
probably some improvements to reduce the number of required passes, as
I'm not convinced I'm running the transformations in a particularly
sensible order).
However, I think making it run in a single pass would be quite difficult
as some of the transformations need to propagate through else if chains
or nested if blocks. It's much easier to just run all the
transformations until they settle than fixing each individual
transformation.
Signed-off-by: Graham <gpe@openrs2.dev>
It's fairly similar to the ComplementTransformer, and translates
expressions like:
!a == !b => a == b
!a == b => a != b
Signed-off-by: Graham <gpe@openrs2.dev>
calculateResolveType() is much more expensive than checking if an
expression is an integer literal, so swap the conditions around.
Signed-off-by: Graham <gpe@openrs2.dev>
Some character literals are treated as integers by Fernflower, as the
complement operator always evaluates to an integer, even if its operand
is a character. This is fine, but ComplementTransformer removes some
complement transformers - leaving integer literals where Fernflower
would normally insert a character literal.
This transformer converts complemented integers to char literals in some
cases where it makes sense (it is difficult to perform this
transformation across every type of expression in JavaParser).
Signed-off-by: Graham <gpe@openrs2.dev>
Unfortunately we can't use the compiler to guarantee k isn't changed,
though making it internal will help. When the JVM (and Kotlin) get value
types, we might be able to improve on this (e.g. by making it an inline
class of four integers).
Signed-off-by: Graham <gpe@openrs2.dev>
This commit improves support for simplifying a series of multiple
additions/subtractions and doing so in a single pass.
Signed-off-by: Graham <gpe@openrs2.dev>
This commit makes two changes:
* Uses the is operator instead of the isXXX methods provided by
JavaParser, allowing smart casts to be used.
* Wraps unsupported expressions with a unary minus expression, rather
than throwing an exception.
Signed-off-by: Graham <gpe@openrs2.dev>
This commit updates the tests to ensure all combinations of 0-7 bytes of
leading/trailing blocks of unencrypted bytes work correctly with all
test vectors.
Signed-off-by: Graham <gpe@openrs2.dev>
We could use LocalVariableTable in theory, but it's more complicated as
we'd need to do live variable analysis and type inference. It's much
easier to leave that for the decompiler.
Signed-off-by: Graham <gpe@openrs2.dev>
The next commit will introduce an ArgRef class which uses a MemberRef
directly, rather than a MemberRef partition.
Signed-off-by: Graham <gpe@openrs2.dev>
