| Age | Commit message (Collapse) | Author |
|---|
|
String literals in annotations can be specified in a static final field instead
of inline (so you can e.g. use the same literal in multiple places).
This commit adds support for remapping those external literals.
|
|
Since 1.3.70, the Kotlin compiler by default uses an internal framework to read
binary Java class files instead of relying on IntelliJ's PSI to do it for them.
This internal framework was introduced in commit d65af8f to reduce the amount of
unnecessary work done by the PSI model.
Our entire mapper was written for the PSI model though (and remains to be
because it must also support Java), so it would fail to remap any Kotlin files
if kotlin-compiler-embeddable was upgraded (for whatever reason) to at least 70
where the new behavior became the default.
Luckily there exists a config flag (renamed in the same version) which allows us
to go back to the PSI reader, so that's what this commit does.
|
|
|
|
|
|
|
|
This e.g. allows the preprocessor to ignore errors in lines which it
would have commented out anyway.
|
|
This is done on a best-effort basis under the assumption that all
relevant methods are part of the mappings (since we don't actually
have access to the remapped MC jar at this point, so we can only check
for ambiguities with the mappings).
|
|
|
|
|
|
i.e. the class string in @Mixin("package.SomeClass$Inner")
|
|
i.e. Fields and methods in @Mixin("package.SomeClass$Inner") but not
the class string itself
|
|
|
|
Lorenz requires inner classes to be separated from their parents by a
dollar sign (i.e. bytecode format), intellij instead by default gives
you source format (i.e. separated by dot, indistinguishable from
packages).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Primarily for potential kotlin support.
Secondarily, this allows us to drop the EPL (kotlin-compiler is ASL2.0).
This also fixes an issue where redirect/inject methods with names
identical to remapped names in the target class would get renamed.
This also seems to implement the implicit member reference check (to
prevent accidental name shadowing after remapping) more thoroughly, at
least it finds some valid cases which the previous implementation has
ignored.
|
|
E.g. A extends B extends C where only C has declared mappings will
prematurely stop searching for C-methods overridden in A because
there are no mappings for B
|
|
These should all be sufficiently covered by the other paths.
|
|
|
|
|
|
|
|
E.g. `isKeyDown` was mapped to `isPressed` and then again to `wasPressed`
Not even sure why that extra call was there in the first place.
|
|
E.g. `Entity#posX` is remapped to `x` which may then be shadowed by
a local variable with the same name.
Since I cannot figure out how to get JDT to give me a list of all
variables in scope at a particular node, the solution employed is to
just forbid any implicit references to remapped members.
This finds quite a few false positives (but not too many to manually
deal with), so I'd be quite happy to switch to another solution if
one becomes available.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
To be specific
- `method` of Inject/Redirect
- `Shadow` members
- `Accessor` methods
|
|
E.g. with mappings:
A to B
B to C
this
A a;
B b;
should map to
B a
C b;
but didn't.
|
|
E.g.
@Getter
private Minecraft mc;
incorrectly remapped to
@MinecraftClient
private MinecraftClient mc;
|
|
|
