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
For MavenDependenciesResolver it improves performance drastically
depending on how strong transitive dependencies of the roots interfere
^KT-61727 Fixed
The call-sites don't actually need to handle unresolved expressions,
they only need safe-casts to ConeClassLikeType or
ConeIntegerLiteralType.
#KT-61367
This prevents exceptions from being thrown during resolution of red code
because FirExpression.resolvedType is called but during annotation
arguments phase we don't have return types for implicitly typed
declarations.
#KT-61367
Dmitriy Novozhilov