| Age | Commit message (Collapse) | Author |
|---|
|
Because `hasMapping` is broken and returns false even when there is a change in
method parameter types. Instead we'll just compare the stringified signature.
|
|
|
|
We may still require some signature changes to make it compile, but these are
generally not relevant for the pattern functionality itself.
|
|
So they can be easily (i.e. without requiring a dedicated file) disabled when no
longer applicable.
|
|
That is, most of the business code should not be aware that it is being compiled
to multiple versions even when it heavily interacts with MC, preprocessor
statements should be an escape hatch, not the norm.
Similarly, code should not be forced to do `MCVer.getWindow(mc)` instead of the
much more intuitive `mc.getWindow()`, and this new preprocessor (technically remap)
feature makes this possible by defining "search and replace"-like patterns (but
smarter in that they are type-aware) in one or more central places which then
are applied all over the code base.
In a way, this is another step in the automatic back-porting process where
preprocessor statements are used when we cannot yet do something automatically.
Previously we "merely" automatically converted between different mapping, this
new feature now also allows us to automatically perform simple refactoring
tasks like changing field access to a getter+setter (e.g. `mc.getWindow()`), or
changing how a method is called (e.g. `BufferBuilder.begin`), or changing a
method call chain (e.g. `dispatcher.camera.getYaw()`), or most other
search-and-replace-like changes and any combination of those.
The only major limitation is that the replacement itself is not smart, so
arguments must be kept in same order (or be temporarily assigned to local
variables which then can be used in any order).
|
|
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;
|
|
|
