| Age | Commit message (Collapse) | Author |
|---|
|
Update from upstream
|
|
|
|
ReplayMod-master
|
|
This reverts commit fcd760df97454eeed436334808da51ea9ba20540.
|
|
Co-authored-by: DJtheRedstoner <52044242+DJtheRedstoner@users.noreply.github.com>
|
|
Fixes #18
|
|
The KotlinSourceRoot constructor was updated to include an additional
argument related to Kotlin Multiplatform. We always pass null for this
argument.
Co-authored-by: Wyvest <wyvestbusiness@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Fixes #13
|
|
|
|
|
|
This adds a post-process step which automatically adds unambiguous imports,
removes unused imports and sorts the import list (formatting matches standard
IntelliJ settings).
This will preserve line count across versions at all cost.
Java only for now because it's a lot more tricky with Kotlin and we don't yet
use Kotlin ourselves (and won't be preprocessing it in the future either).
|
|
|
|
|
|
|
|
Used to only compare the arguments, nether the class nor the qualifier (the
outer class instance for inner classes constructor calls).
|
|
|
|
|
|
While, unlike last time, maintaining backwards compatibility with 1.5.21 (and
anything in between).
|
|
Any annotation in a mixin class that has a `method` will do.
This will mean it doesn't need updating for future stock injectors, and doesn't break with custom injectors.
|
|
|
|
|
|
|
|
|
|
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.
|
|
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.
|
|
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).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
