In order to properly analyze top-level property initialization, a
control-flow graph must be created for FirFiles. This change adds the
foundation for the file CFG and updates body resolve to create the CFG.
Checking the CFG for proper initialization is separated into a following
change to ease code review.
KT-56683
This change is necessary in order to make `FirElement` abstract class. To do it we need to remove all `accept` and `transform` methods from fir interfaces. So we have to make sure that all fir element implementations have their `accept` and `transform` implementations in their super classes. In particular this change makes 'accept' and 'transform' methods in `FirConstructedClassTypeParameterRef` and `FirConstructedClassTypeParameterRef` base classes.
This change is necessary in order to make `FirElement` abstract class. To do it we need to remove all `accept` and `transform` methods from fir interfaces. So we have to make sure that all fir element implementations have their `accept` and `transform` implementations in their super classes. In particular this change makes `FirImport` abstract class in order to preserve `accept` and `transform` methods after removing them from fir interfaces.
Previously, when no file annotations were present, the FIR element
didn't have a source.
By making it nullable, it will only be created when appropriate and the
source will never be null.
#KT-55835
This is needed because of mutable nature of receiver values: implicit
receiver values can be modified because of smartcasts, but in candidate
we need to store snapshot of receiver in the form it was at the beginning
of the resolution
^KT-58823 Fixed
This commit adds missing pieces for the puzzle:
Annotation instantiation feature uses IrProperty's initializer to instantiate
properties from other modules that have default values which weren't
specified on call site.
To support this feature properly, Fir2IrVisitor should fill LazyIrProperty's
backing field initializer with information from Fir.
To get this information into Fir, FirMemberDeserializer should be able to read
it from KotlinJvmBinaryClass with AnnotationLoaderVisitorImpl. (klibs are unsupported for now)
There's a catch with enum entries references: we can't access session.SymbolProvider to resolve it
because we're still at the deserialization stage, and it can cause StackOverflow if enum is nested in the
same class (see RequiresOptIn.Level). To mitigate this, a new FirEnumEntryDeserializedAccessExpression is produced
instead; it is later replaced with the correct reference in the Fir2IrVisitor.
^KT-58137 Fixed
Also add test to loadJava folder with annotations default values that
verifies metadata loading
The basic idea is that during deserialization/loading compiled
Java classes, there might be some of the dependencies absent that
are referenced from enum arguments in annotations.
Such situation is not considered as totally ill-formed, thus supporting
it, allowing to read the names of mentioned in the annotation argument
might be useful for Java enhancement
^KT-56656 In Progress
The implementation is rather limited. Advanced cases, such as
replacing a script with another one with different import directives,
won't work because of non-trivial relationship between 'FirFile' and
'FirScript'.
Dmitriy Novozhilov