For some reason type parameters end up in
`GlobdalDeclarationTable`, and thus we tracked them in
`IdSignatureClashDetector`, which wasn't right and confused the
diagnostic renderer that uses
`org.jetbrains.kotlin.resolve.MemberComparator` for sorting the
declarations to display in diagnostics. That comparator doesn't know
jow to work with type parameters.
Besides, type parameters, like many other types of declarations, are not
considered public wrt KLIB ABI, so there's no need to show
CONFLICTING_KLIB_SIGNATURES_ERROR for them.
^KT-65723 Fixed
Copying tree part happens in two stages.
1. Collect all symbols to copy and create new version of them
2. Do copy tree, replacing collected symbols
For f/o builder 1-st stage traversed more nodes, than seconds.
This led to unbound symbols in tree.
^KT-65273 Fixed
There's no issue or tests because it doesn't affect user-visible
behavior. The only effect of this change is that after IR fake override
builder is enabled by default (KT-61360), tests in
`compiler/testData/ir/sourceRanges` will now pass because using class
start/end is the current behavior in K2 and test data checks it.
Show what kind of declarations exactly are clashing: functions,
properties, or fields.
This is so that diagnostics about clashing properties and fields are
distinguishable from one another, since properties and fields
are rendered the same way in those diagnostics:
The issue was that when rendering declarations in
the `CONFLICTING_KLIB_SIGNATURES_DATA` diagnostics, we sort them using
`MemberComparator`. That comparator falls back to comparing
declarations' renders if all previous checks were unsuccessful
(and in case of almost identical properties they are). The renderer that
the comparator uses also renders the properties' backing field
annotations, for which it calls `PropertyDescriptor#getBackingField`.
That method wasn't implemented in IR-based descriptors.
This is fixed by returning an instance of the new
`IrBasedBackingFieldDescriptor` class from that method.
^KT-65551 Fixed
- `CompilationException` should not strongly reference `IrFile`s and
other IR elements, which in turn reference FIR elements strongly. It
can lead to a memory leak in the IDE as the exception is held
statically in the IDE's `MessagePool`.
- I considered fixing this on the level of `KtCodeCompilationException`
from the Analysis API, but:
1. `KtCodeCompilationException` can wrap many kinds of exceptions.
Snapshotting the cause only for `CompilationException` (somewhere
down the cause chain) would be messy, as it'd require traversing
the cause chain and referencing `CompilationException` directly,
breaking API boundaries.
2. Keeping the same level of report quality while snapshotting a cause
is not trivial.
3. Exceptions in general should be as lean as possible, so it makes
sense to fix `CompilationException` itself.
^KT-65655 fixed
- remove ENABLE/COMPATIBILITY because they can no longer be used
- remove forAllMethodsWithBody because its behavior is now equivalent to
isEnabled
- inline isCompatibility
- inline DEFAULT
- rename ALL_INCOMPATIBLE -> ALL
We only want to report signature clashes for declarations that come
from the module currently being serialized. In GlobalDeclarationTable,
declarations from other modules could also be stored.
Checking whether a declaration is a Lazy IR declaration to
determine if it comes from an external module works okay, but it is
a hack which relies on an implementation detail of IR, which may or
may not work in the future.
Use a more robust logic here, since IrFileSerializer is always aware
which declarations are declared in the current module and which are
just referenced from it.
Otherwise it leads to the following problem in the newly added test.
Suppose that we have a fake override `remove(Int)` inherited from
LinkedList _without_ EnhancedNullability on its parameter type. By
normal Kotlin rules, this method should override the method from
KotlinInterface. However, on JVM we have another overridability check in
IrJavaIncompatibilityRulesOverridabilityCondition which ensures that
"JVM primitivity" of parameter types is the same for the base and the
overridden method.
So the fake override `remove(Int)` from LinkedList is determined to be
override-incompatible with `remove(Int)` from KotlinInterface. But when
we try to create symbols for all fake overrides in the class, we get a
clash because there are two fake overrides with exactly the same
IdSignature, neither of which overrides the other.
If we keep the EnhancedNullability annotation on the parameter, it
starts working because the logic of computing signature in
JvmIrMangler.JvmIrManglerComputer.mangleTypePlatformSpecific adds an
"{EnhancedNullability}" mark to the IdSignature of a fake override from
LinkedList.
#KT-65499 Fixed
This is kind of another fix for KT-65456, independent from the one in
the previous commit. Here we restore the old behavior of
`buildFakeOverridesForClassUsingOverriddenSymbols`, which is used in
places where fake overrides for static declarations from
superclasses are not necessary at all, such as SAM adapters or
annotation implementation classes.
This reverts commit 6271f5cbe5.
The original commit 15094eb03a was reverted because it caused a problem
during bootstrap. That problem is fixed in a subsequent commit.
To add the file name to the exception message similarly to how it's done
in `PerformByIrFilePhase.invokeSequential`, so that exceptions such as
KT-65277 would be easier to diagnose.
If we encounter a declaration in the current module whose signature
is the same as that of a declaration in another module which we happen
to also reference from the current module, don't report any errors,
just like we don't do it in Kotlin/JVM. This leaves the user in the KLIB
hell situation, but this is intentional, because otherwise a legitimate
change like moving a declaration to another module and marking
the original one as `@Deprecated("", level = DeprecationLevel.HIDDEN)`
would lead to a error, and we don't want that.
Also, don't try to show the diagnostics on a declaration that doesn't
have an IrFile.
^KT-65063 Fixed
Pass the metadata serializer instance instead. This allows to further
reduce code duplication by introducing the common interface
`KlibSingleFileMetadataSerializer` for abstracting away K1 and K2
representation of a source file, as well as reusing
`Fir2KlibMetadataSerializer` across different backends.
KT-64392
Substitution of type arguments to non-reified type parameters may lead
to accidental reification, which should not be done (see ^KT-60174 for
examples). So, we should erase them, except the few cases.
^KT-60174: Fixed
^KT-60175: Fixed
Motivation of using dispatch receiver type when calculating method owner
was discussed here: https://github.com/JetBrains/kotlin/pull/3054
However, this is incompatible with type erasure of non-reified type
parameters on inlining (which will be done in future). Consider the
code:
```
inline fun <T> f(arr: Array<T>, p: (T) -> Int): Int = p(arr[0])
fun box() = f(arrayOf("abacaba"), String::length)
```
After inlining and erasure, the type of `arr[0]` is `Any`. Thus, when
calculating owner of `String::length` we would have `Any` instead of
`String` if we used dispatch receiver type.
Note, that this change affects bytecode instruction that invokes
method, but does not change which method is being invoked.
This is more convenient behaviour for debugging with klib-tool than
just failing.
Note that enabling Partial Linkage globally in klib-tool is undesirable,
as it can auto-tweak IR (e.g. when overrides do not match), thus
distorting the rendered IR
^KT-61143 Fixed
Pavel Kunyavskiy