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'.
Previously `FirPropertyAccessor.source` references the `KtProperty` if
the user code contains a setter or getter that doesn't contain a body.
For example, with the following
```
val i: Int = 1
private set
```
The `FirPropertyAccessor` would reference the `KtProperty` as the
source.
This change makes `FirPropertyAccessor` reference `KtPropertyAccessor`
as the source if possible, regardless of whether the body is present or
not.
Move it to build-common where it's still used in incremental compilation
caches, and simplify a bit. In the future, it'll make sense to remove it
completely and to avoid writing it to caches. In this commit, I don't do
that to prevent the IC cache version to be updated, causing rebuilds for
all JPS projects.
#KT-41758
Since nullability-flexible types in IR are represented by an annotation
on an IrSimpleType, not a special instance, the common implementation of
`KotlinTypeMarker.isMarkedNullable` in `TypeSystemContext` doesn't work.
This method is used for example to generate `typeOf` in JVM IR, in
`TypeSystemCommonBackendContext.generateTypeOf`, and this issue led to a
difference in behavior of `typeOf` for nullability-flexible types.
#KT-44726 Fixed
There was a problem with delegated extension property with dispatch
receiver that `this` in `getValue` call was set to dispatch receiver
instead of extension one
Pavel Semyonov