If some of builtin classes is declared in sources, trying to load it in
IrBuiltInsOverFir before fir2ir pass which generates IR for source
declarations will lead to creating lazy class instead of normal one
Without this change the following tests are failing:
- `FirLightTreeBlackBoxInlineCodegenWithBytecodeInlinerTestGenerated.Signature`
- `testByteIteratorWithWhileLoop`
- `testByteIteratorWithForLoop`
Accessing list of declaration may trigger lazy declaration list computation for lazy class,
which requires computation of fake-overrides for this class. So it's unsafe to access it
before IR for all sources is built (because fake-overrides of lazy classes may depend on
declaration of source classes, e.g. for java source classes)
So this OptIn is needed to carefully handle all cases of .declarations access in FIR2IR
There was a case when we visited the same declaration multiple times
because of forward-referencing and visiting with designation
So because of this there were two changes required:
- remove assertion about visiting the same declaration twice (it's fine
since we don't actually resolve annotations twice)
- not skipping resolution of class children if annotations on this class
are already resolved
^KT-61388 Fixed
KT-62854
In the previous commit, we started to treat delegated function similarly
to substitution/intersection overrides, so now it's incorrect to name
corresponding methods and storages using "fake-override" word
^KT-62671
Delegated callables in FIR are session-dependant (as fake-overrides),
so it's incorrect to use their FIR as a key for declaration storage.
Pair of original function and owner lookup tag should be used instead
^KT-62671 Fixed
Previously, creating a declaration with Fir2IrCallableDeclarationsGenerator/
Fir2IrClassifiersGenerator didn't guarantee that this declaration will
be actually added to the list of parent class/file declarations, which
lead to situations when FIR2IR created some declarations in the air
(mostly fake-overrides)
It is needed to have an ability to distinguish those two cases in FIR2IR:
Without this change the following tests fail:
- org.jetbrains.kotlin.test.runners.codegen.FirPsiBlackBoxCodegenTestGenerated.Enum
- testEnumEntryReferenceFromInnerClassConstructor1()
- testEnumEntryReferenceFromInnerClassConstructor2()
- testEnumEntryReferenceFromInnerClassConstructor3()
- testInnerClassMethodInEnumEntryClass()
- testInnerClassMethodInEnumEntryClass2()
- testKt9711_2()
- testDeepInnerClassInEnumEntryClass()
- testKt7257_boundReference1()
- testInnerClassInEnumEntryClass()
- testKt44744_innerClass()
For reasoning refer to the message of the previous commit
It is the same as for `getIrFunctionSymbol`
There is one failing test here, caused by KT-61941
The issue was here before this commit, but it was hidden
It's incorrect to create fake-overrides with `getOrCreateIrFunction/Property`
call. FakeOverrideGenerator should be used instead. So this commit
just changes the place which creates static f/o generated from
I failed to reproduce the corresponding failure in compiler tests, but
without this change FP Kotlin test fails
Previously `getIrFunctionSymbol` effectively did the same thing as `getOrCreateIrFunction`,
but in a slightly different way. To avoid logic duplication and source of
potential inconsistencies, implementation was changed to just delegate to
`getOrCreateIrFunction`
Changes in `computeIrOrigin` were required because origin for callables in
`getOrCreateIrFunction` and `getIrFunctionSymbol` was computed differently,
so `computeIrOrigin` was changed to preserve existing behavior
^KT-60924
Reporting of those errors was implemented as an ad-hock solution for part
of the KT-58881, and it was implemented incorrectly. There won't be any
need in this reporting in actualizer after KT-58881 will be fixed, so
there is no actual sense to fix their implementation in actualizer itself
(as it will be removed)
Effectively, `getIrFieldSymbol` always created `IrField` if it was needed
and returned its symbol. So to avoid potentially unsafe access of
`IrFieldSymbol.owner` it's more convenient to return directly `IrField`
^KT-60924
Effectively, `getIrClassSymbol` always created `IrClass` if it was needed
and returned its symbol. So to avoid potentially unsafe access of
`IrClassSymbol.owner` it's more convenient to return directly `IrClass`
^KT-60924
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
Fir2IrAnnotationsFromPluginRegistrar stores elements using start and end
offsets from IR elements, which strip comments from the start offset.
So it's also needed to strip it from FIR source to keep the consistency
^KT-61872 Fixed
Test dump for klib does not correlate to real case (CLI compilation of
JS or Native), because for some reason KLib facade in MPP scenario
uses session/module of each specific file, instand of session for
leaf platform module
In CLI scenario only one session is used, so annotations are generated
properly
^KT-61833 Fixed
This is needed for two purposes:
- sometimes dependencies may differ because of changes in KGP, and it's
better to find it right after version-update commit, not only at remote run
- there is a plan to drop `trusted` section from `verification-metadata.xml`
and always set specific versions of used dependencies even for bootstrap
dependencies, so running it in regular bootstrap update routine won't
allow forgetting about it (see KTI-1374)
There was only one real inheritor of AbstractFirBaseDiagnosticTest,
so there is no need in the whole hierarchy of abstract test runners
Also AbstractFirOldFrontendLightClassesTest is not intended to check any
diagnostics or CFG dumps, so this logic was removed (they still can be
checked using non-legacy AbstractFirDiagnosticTest from the main test
infrastructure)
^KT-61640 Fixed
This change doesn't affect any tests in the moment, because it's part of
bigger refactoring of proper storing IR declarations during FIR2IR
conversion (KT-61637)
Without this change, there is one test break in branch for KT-61637:
- FirPsiBlackBoxCodegenTestGenerated.Multiplatform.K2.testJavaMethodWithTypeParameter
This is needed for two reasons:
1. common and platform modules are analyzed in the same setup with same
dependencies and configurations, so the results of the enhancement for
any function will be completely identical. So by sharing enhanced
symbol storage, we avoid recomputation enhanced functions and improve
performance
2. There is a goal to have some unique key for IR declarations in FIR2IR.
For regular declarations, the key is just Fir symbol, and for fake-overrides
it is a pair of original symbol and fake override owners lookup tag.
But for enhanced functions the symbol is not unique, because we create
different symbols for the same enhanced function for different modules.
So this change fixes this problem
^KT-60397 Fixed
This change doesn't affect any tests in the moment, because it's part of
bigger refactoring of proper storing IR declarations during FIR2IR
conversion (KT-61637)
Without this change, there are some test breaks in branch for KT-61637:
- FirPsiBlackBoxCodegenTestGenerated.Multiplatform.testStarImportOfExpectEnumWithActualTypeAlias
- FirPsiBlackBoxCodegenTestGenerated.Multiplatform.K2.DefaultArguments.testNestedEnumEntryValue
- FirPsiBlackBoxCodegenTestGenerated.Multiplatform.K2.Basic.testEnumEntryNameCall
There is a case when we shouldn't hide a function even if it overrides
builtin member with value parameter erasure: if substituted kotlin
overridden has the same parameters as current java override. Such
situation may happen only in case when `Any`/`Object` is used as
parameterization of supertype:
// java
class MySuperMap extends java.util.Map<Object, Object> {
@Override
public boolean containsKey(Object key) {...}
@Override
public boolean containsValue(Object key) {...}
}
In this case, the signature of override, made based on the correct
kotlin signature, will be the same (because of { K -> Any, V -> Any }
substitution for both functions). And since the list of all such
functions is well-known, the only case when this may happen is when
value parameter types of kotlin overridden are `Any`
This change doesn't affect any tests in the moment, because it's part of
bigger refactoring of proper storing IR declarations during FIR2IR
conversion (KT-61637)
Without this change, there is one test break in branch for KT-61637:
`FirPsiBlackBoxCodegenTestGenerated.SpecialBuiltins.testMapGetOrDefault`
I don't really know which exact commit fixed this test, but there was
a problem with return types of delegated members. Before my changes
delegated `override fun foo(x: Int)` in `actual class E` had error
return type and now it has correct type `Int`
Group methods of Fir2IrClassifierStorage and Fir2IrClassifiersGenerator
by types of declarations they are working with.
This commit contains nothing but just moving code in borders of the same file
Dmitriy Novozhilov