In PSI world, a call to super type constructor is represented by a
KtSuperTypeCallEntry. Currently FIR tracks the callee reference to this
constructor call.
This is undesirable because
1. We may want to report issues on the call arguments, so FIR must track
the entire call rather than just the callee reference
2. Light tree actually reports the KtSuperTypeCallEntry.
3. Both the FirDelegatedConstructorCall and its `calleeReference` are
currently referencing the same KtConstructorCalleeExpression PSI
element as the source.
This change makes FirDelegatedConstructorCall track the entire
KtSuperTypeCallEntry as the source, if possible.
Before this fix, if some imports were not resolved during compilation,
this result had been saved in caches, and this import couldn't been
resolved during following compilations even if it was added to the
module dependencies. This commit adds special handling of resolution
caches for the REPL compiler.
This has no effect on correct code because extension properties cannot
have a backing field anyway and that is checked separately. But this
function is used in psi2ir to determine whether or not to create a
backing field for a property, and in case the code where the property is
declared is unreachable like in KT-44496 and has no explicit getter or
setter, it would previously return true for extension properties, which
on JVM would result in an actual field in the class file, which made no
sense.
After this change, the compiler will actually crash with an exception in
the IR validaton step because the symbol for the field is unbound. That
is a bit better than proceeding to generate potentially invalid
bytecode, but of course a proper fix would be to report an error in the
frontend.
#KT-44496
Compiler check for 'when' exhaustiveness requires that module
descriptors of a sealed class and its inheritors are the same (reference
identity matters). Prior to this commit and under some conditions they
were not. Details follow below.
Resolution related data structures (resolution facades) are organized
into trees (sdks, libs, and modules have their own nodes/facades,
module/class descriptors are stored inside). And the trees themselves
are put into a map associating so called PlatformAnalysisSettings and
GlobalFacades (plays a role of a root). PlatformAnalysisSettings is an
abstraction describing target platform and sdk of a module. The more
combinations exist for a project the more facades are used. Please, see
KotlinCacheService for more details.
So why a module can have multiple ModuleDescriptor-s?
Every tree mentioned above is an isolated resolution environment
containing its own instances of the outer world descriptors. Say, if a
project has modules X, Y, Z and we consider X then all three might have
their own vision of X, i.e. 3 descriptors exist at a time.
What descriptor instance does compiler get?
The path starts when the user opens a file in the editor and
highlighting pass starts (see usages of
ResolutionUtils#analyzeWithAllCompilerChecks). Module descriptor stored
in the resolution tree of the file's module gets injected into the
compiler's context. Starting from this moment compiler sees other
modules through the prism of a single resolution facade (tree).
Descriptors residing outside are alien.
This commit allows IdeSealedClassInheritorsProvider to figure out what
PlatformAnalysisSettings are associated with the resolution facade (read
ModuleDescriptor) seen by the compiler. Later on the same facade is used
to provide correct instances of sealed inheritors back to the compiler.
Note that LazyClassMemberScope actually has a separate field for
KotlinTypeRefiner, and it might be actually different from the one in
c.kotlinTypeChecker.
The one in c.kotlinTypeChecker is the refiner of *owner* module, i.e. a
module in which the class has been declared. If we have a class Foo :
Expect in common, then the refiner will be from common, and thus it
won't be able to refine supertypes to their platform-dependent values.
The one passed in constructor is actual refiner of dependant-module.
Say, if we're looking at Foo from the point of view of jvmMain, then
we'll create a (view-dependent) LCMS for that, and it will contain
refiner for jvmMain.
It is important to use proper refiner, otherwise the idea of having
"module-dependent view" breaks, and we might suddenly mismatch some
overrides with expect-classes in their signatures.
^KT-44898 Fixed
Extract a service interface out of ControlFlowInformationProviderImpl
and register its implementation in two "leaf" modules: 'cli',
'idea-core'.
This improves parallel build, since a lot of modules depend on
'frontend' but only these two modules reference the implementation and
thus depend on the full CFA implementation now.
Do not use default parameter value for functions with only 1 or 2 call
sites, since it doesn't add much value but provides a dangerous
possibility to forget to pass the real implementation.
This is needed in order to have a single convenient place where to
register frontend services implemented _outside_ of the 'frontend'
module, such as the control flow analysis, extracted to a separate
module in a subsequent commit.
These utilties are used not only within CFG, but from the frontend and
idea as well. Therefore upon extraction of CFG into another module,
these two new files will remain in 'frontend'.
Igor Chevdar