| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
While one might at first think that multiple changes should conflict if they
target that same start point, that is not necessarily true as long as no more
than one of them includes deletions: There may be an arbitrary number of
insertions at the same position (regular remapping never just inserts but
patterns can).
|
|
|
|
We seem to no longer be relying on it too much. There are still a few issues
which have gone unnoticed due to this bug but those will be fixed in the
following commits.
|
|
When we used to remap `a.pkg.A.Inner` we would apply both mappings (the one for
the inner class and the one for the outer class) at the same time, resulting in
`b.pkg.B.Inner.Inner`.
The direct cause being that we only checked conflicts for the range of the
respective expression (which is just `A` and `Inner` for Kotlin, and therefore
not conflicting) instead of the parent as we should have.
With that fixed, it now also becomes apparent that we need to apply mappings for
dot qualified expressions back to front (otherwise the outer class takes
priority), so that is the second thing this commit change.
|
|
When remapping the @At `target` argument, we used to only look at the mappings
for the target class but we also need to consider mappings for its super classes
and interfaces.
This commit now searches for the target Psi method and then uses the regular
remap method for PsiMethod to get its properly mapped name.
|
|
To ensure the mixin target is being remapped, even though the corresponding
PsiClass cannot be found.
|
|
E.g. there are no mapping entries for constructors cause their name is always
`<init>` but we nevertheless want to remap their argument types.
We cannot determine whether the name is ambiguous in the mapped
environment (because that check is based on the mappings), so we always keep the
arguments when it previously had ones.
|
|
When remapping the injector target argument (`method`), we used to only look at
the mappings for the mixin target class but we also need to consider mappings
for its super classes and interfaces.
This commit now searches for the target Psi method and then uses the regular
remap method for PsiMethod to get its properly mapped name.
It still only looks at the target class mappings to determine whether the new
name is ambiguous because we do not have access to the remapped target class
hierarchy.
|
|
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.
|
|
|
|
Kotlin 1.5 requires at least Gradle 6.8.3.
|
|
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.
|
|
|
|
|
