aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2021-11-13Support multi-target mixin injectorsJonas Herzig
2021-11-13Implement synthetic property to/from setter conversionJonas Herzig
2021-11-13Move mixin-related tests into their own packageJonas Herzig
2021-11-13Consider location of expression when determining field accessibilityJonas Herzig
A protected field is not accessible unless we are referencing it from within a class which extends its owner. Therefore, we may use a synthetic property with the same name as long as we do not have access to the field.
2021-11-13Fix mapping of synthetic properties when overridden in Kotlin classJonas Herzig
In these cases, the getMethod of the property will not have a Psi element and we need to traverse up the overrides until we find one that does.
2021-11-12Separate B from A test filesJonas Herzig
So we are closer to a realistic setup and can tell when we accidentally look up a class in the wrong project. Also allows us to have changes in a class but not to the class or its package (i.e. same file).
2021-11-12Fix synthetic property becoming shadowed by field of same nameJonas Herzig
2021-11-12Add `findPsiClass` method to PsiMapperJonas Herzig
2021-11-12Remove obsolete commentJonas Herzig
2021-11-12Add tests for Kotlin synthetic propertiesJonas Herzig
2021-11-12Fix inject method in constant being duplicated if remapped twiceJonas Herzig
2021-11-12Fix @At target in constant being duplicated if remapped twiceJonas Herzig
2021-11-12Fix loss of changes when multiple target the same start pointJonas Herzig
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).
2021-11-12Fix methods in mixin being remapped when they should not beJonas Herzig
2021-11-11Fix `valid(PsiElement)` methodJonas Herzig
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.
2021-11-11Fix remapping of qualified inner class reference in Kotlin codeJonas Herzig
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.
2021-11-11Fix mixin @At target not considering mappings from parent classesJonas Herzig
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.
2021-11-10Add test for anonymous inner class mixin targetJonas Herzig
To ensure the mixin target is being remapped, even though the corresponding PsiClass cannot be found.
2021-11-10Remap mixin injector target arguments even when method is not mappedJonas Herzig
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.
2021-11-10Fix mixin injectors not considering mappings from parent classesJonas Herzig
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.
2021-11-10Fix legacy mapping set stripping descriptor when it should notJonas Herzig
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.
2021-11-10Start adding testsJonas Herzig
2021-08-20Merge branch 'kotlin-1.5'Jonas Herzig
2021-08-20Bump Kotlin version to 1.5.21 (Gradle 7.2)Jonas Herzig
2021-06-05Skip pattern if body (not the entire method) is unchangedJonas Herzig
We may still require some signature changes to make it compile, but these are generally not relevant for the pattern functionality itself.
2021-06-05Ignore pattern if either method body is emptyJonas Herzig
So they can be easily (i.e. without requiring a dedicated file) disabled when no longer applicable.
2021-05-13Bump Kotlin version to 1.5.0Jonas Herzig
2021-05-13Update Gradle to 7.0.1Jonas Herzig
Kotlin 1.5 requires at least Gradle 6.8.3.
2021-03-14Add new @Pattern feature to centralize version-aware codeJonas Herzig
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).
2021-03-14Kotlin source remapping has indeed been supported for a while nowJonas Herzig
2020-11-22Support remapping of mixin targets declared in static fieldsJonas Herzig
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.
2020-11-21Update kotlin-compiler-embeddable to 1.3.72Jonas Herzig
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.
2020-05-22Properly dispose of root Disposable once doneJonas Herzig
2020-05-22Fix thread-unsafe extension point registeringJonas Herzig
2019-12-08Support remapping other mixin injection annotations (fixes #6, fixes #7)Jonas Herzig
2019-12-08Move remap error handling to the callerJonas Herzig
This e.g. allows the preprocessor to ignore errors in lines which it would have commented out anyway.
2019-12-08Disambiguate Inject/Redirect targets where necessary (fixes #5)Jonas Herzig
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).
2019-12-07Remap string mixin target in `package.Outer.Inner` form (fixes #3)Jonas Herzig
2019-12-07Remap non-getter to synthetic property where possible (fixes #2)Jonas Herzig
2019-11-02Support remapping of string-typed mixin targetsJonas Herzig
i.e. the class string in @Mixin("package.SomeClass$Inner")
2019-11-02Support remapping in mixins with string-typed targetsJonas Herzig
i.e. Fields and methods in @Mixin("package.SomeClass$Inner") but not the class string itself
2019-11-02Support remapping of simple @Invoker targetsJonas Herzig
2019-11-01Fix remapping when inner classes are in playJonas Herzig
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).
2019-11-01Fix crash when synthetic property is re-mapped to non-propertyJonas Herzig
2019-11-01Add methods for parsing legacy mappings from string instead of fileJonas Herzig
2019-09-15Add support for remapping Kotlin filesJonas Herzig
2019-09-08Support remapping @At(NEW) targets (i.e. jvm class name targets)Jonas Herzig
2019-08-31Use -embeddable compiler for compatibility with kotlin gradle pluginJonas Herzig
2019-08-30Convert implementation and build script to KotlinJonas Herzig
2019-08-30Update embedded kotlin compiler version from 1.3.31 to 1.3.40Jonas Herzig