There is IDE quick fix which suggests to copy mismatched annotation
from `expect` to `actual` (see KTIJ-26633). It needs to find
`actual` PsiElement where to add annotation. Before previous commit, it
was easy - just get source of `Incompatibility.actualSymbol`.
After previous commit, the problem might be in value parameter, while
`actualSymbol` would contain function symbol. This is solved by adding
new field `Incompatibility.actualAnnotationTargetElement`.
`SourceElementMarker` introduced, because it's needed to be used in
abstract checker. Existing `DeclarationSymbolMarker` doesn't fit
because in next PR for this issue annotations set on types will be reported,
and types are not declarations.
^KT-60671
Comment was added to make it clear why whole declarations reported
in diagnostic instead of value parameter symbols (same will be done
with other targets in subsequent commits).
^KT-60671
Since CompilerOptions and LanguageSettings are synchronized between
each other, we don't need this additional sync that actually duplicates
arguments.
^KT-61700 Fixed
`FakeOverrideBuilder.provideFakeOverrides` recursively changes overrides
for all superclasses in the hierarchy, including lazy IR, which is a lot
of extra work.
Also it leads to some tests failing in the IR fake override builder mode
because it changes correct fake overrides of Java classes to incorrect
ones. Those tests are unmuted but it doesn't mean they are fixed -- most
likely we'll generate fake overrides via IR for lazy IR too, at which
point they'll start to fail again.
Make the declaration external at the call site instead of creating two
instances of FakeOverrideCopier. It's possible because IR elements are
mutable, in particular isExternal is a var.
Maybe the same should be done to IrUnimplementedOverridesStrategy, but
that is postponed for another time.
Fake overrides created by K1, as well as fir2ir in K2, use DEFINED. So
this gets rid of a lot of differences in IR text dumps between the K2
normal mode and K2 with IR fake overrides, and will ultimately help in
implementing and testing KT-61360.
The change in AddContinuationLowering is needed to fix tests like
kt47549. When creating anonymous classes for SAM implementations, we're
reusing the same fake override building machinery. And since we can't
extract any meaningful information from the fake override parameter's
origin anymore, we have to get the parameter from the original symbol.
For example, `java.util.ArrayList.elementData` is a generic
package-private method. Not unwrapping intersection/substitution fake
overrides resulted in incorrect FQ names being compared in the package
visibility check, which led to the fake override always being created in
any subclass of ArrayList.
This change will help in testing IR fake overrides (KT-61360) because in
the current (temporary) mode, IrFakeOverrideRebuilder throws an
exception if initial fake overrides constructed by fir2ir differ from
the ones rebuilt by the IR -- and here they'll be different after fixing
KT-61366.
It is incorrect because has expect and actual in same module,
which results in ACTUAL_WITHOUT_EXPECT reported in FIR.
But there is already same test
`multiplatform/incDecOperatorsInExpectClass.kt`, so there is no need
to fix and maintain test `IncDecOperatorsInExpectClass`.
^KT-60075 Fixed
Without this change, the following test is failing:
- FirLightTreeBlackBoxCodegenWithIrFakeOverrideGeneratorTestGenerated.Collections.testInheritFromHashtable
^KT-58861
Previously fir2ir created real IR properties some getter and setter for
such references, which lead to the situation that there might be a
unbound fake override for synthetic property which wasn't stored in
declaration storage (and code in FakeOverrideGenerator was a hack
to cover this case)
In the same time K1 creates fake property for such cases, which is stored
in IrPropertyReference along with original get... and set... functions
as getter and setter of reference. And in this commit K2 does the same thing
^KT-61637
Without this change, the following tests will fail:
- `FirLightTreeBlackBoxCodegenTestGenerated.InlineClasses#testJavaPrimitiveTypeIC`
- `FirLightTreeBlackBoxCodegenTestGenerated.InlineClasses#testJavaPrimitiveTypeICGeneric`
- `FirPsiJvmIrTextTestGenerated.Classes.DataClasses#testKt31649`
^KT-61637
There is a difference in how FIR and IR treat synthetic properties (properties built upon java getter + optional java setter)
For FIR they are really synthetic and exist only during call resolution, so FIR creates a new instance of FirSyntheticProperty
each time it resolves some call to such property
In IR synthetic properties are fair properties that are present in IR Java classes
This leads to the situation when synthetic property does not have a stable key (because FIR instance is new each time) and the only
source of truth is a symbol table. To fix it (and avoid using symbol table as a storage), a pair of original getter and setter is
used as a key for storage IR for synthetic properties. And to avoid introducing special cache of FirSyntheticPropertyKey -> IrProperty
additional mapping level is introduced
- FirSyntheticPropertyKey is mapped to the first FIR synthetic property which was processed by FIR2IR
- this property is mapped to IrProperty using regular propertyCache
^KT-61637
Previously, DataClassMembersGenerator saved generated functions only in
symbol table, which led to the situation when there is a FIR function
in scopes, IR function in symbol table but no record about their relation
in Fir2IrDeclarationStorage
^KT-61637
The checker also checks the metadata version, which
would be handled separately. Now it would never
emmit this error for klib-based backends.
^KT-61773
^KT-61596
^KT-55809
This is an addition to d16f33cf5b. Apparently there's another call site
of JvmIrCodegenFactory in intellij besides Evaluate Expression, namely
Android LiveEdit plugin, where it seems needed to collect all dependency
modules and resolve them via linker. LiveEdit also uses
shouldStubAndNotLinkUnboundSymbols = true, so we need to differentiate
between it and Evaluate Expression, hence the new flag. This new flag
will be set to true only for Evaluate Expression in intellij.
#IDEA-329915
Ilya Goncharov