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>
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>
Fixes a problem where `Constructor<?> var0 =
clazz.getDeclaredConstructor(); return var0.newInstance();` was transformed to
`Constructor<?> var0 = clazz.getDeclaredConstructor(); return
var0.getDeclaredConstructor().newInstance();`
Signed-off-by: Desetude <harry@desetude.com>
This is a special case, so I've just hard-coded the GlEnum name and
value. Luckily its value is only used in the client in an OpenGL
context.
Signed-off-by: Graham <gpe@openrs2.dev>
It's actually hard to determine whether to use a vendor suffix or not.
For example, the client sometimes uses a bunch of *ARB functions with
_ARB constants. However, it uses the non-_ARB constant with glGetFloat.
It's very hard to fix this inconsistency while still using vendor
suffixes. It seems much easier to just use the constants without the
suffixes all the time.
Signed-off-by: Graham <gpe@openrs2.dev>
This picks up a glGetString(GL_EXTENSIONS) constant.
Don't translate gl calls within the jaggl.opengl class itself. This
causes failures as there are native methods with 0 and 1 suffixes. These
methods don't exist in the OpenGL registry, causing the transformer to
throw an exception.
Signed-off-by: Graham <gpe@openrs2.dev>
Desetude noticed that there are some cases where this transformation is
unsafe - for example: `i > i++`. Skipping the transform if _either_ side
of the comparison has a side effect, rather than _both_ sides, makes it
safe.
