Methods of the common interface DeclarationFactory were only used in
lowerings in InnerClassesLowering, which were used in JVM and JS, not
Native. Therefore, it makes sense to have this as a separate interface
and pass its implementation to these lowerings directly, instead of
declaring it in the common context (which is not going to be implemented
in Native).
In case of initializing property or function with anonymous object the
object is being exposed outside its field/function's scope and
accessible on previous level. In this case in `declarations only` mode
we have unbound symbols. Fix is to force body/initializer loading in
such cases.
Make sure it is deserialized in `declarations'only` mode too.
- Fix KT-40216
- Add test
This is needed to get rid of the diamond hierarchy:
IrMemberAccessExpression
/ \
/ \
IrFunctionAccessExpression IrCallableReference
\ /
\ /
IrFunctionReference
In the subsequent commit, IrFunctionReference no longer inherits from
IrFunctionAccessExpression; the more precise type of `val symbol:
IrFunctionSymbol` is now carried via the generic type argument.
This will help to refactor IR element hierarchy from interfaces to
classes, improving performance of visitors and transformers.
Work with the corresponding base interfaces instead. This change will
help in moving the IR element hierarchy from interfaces to classes,
should the need arise.
There's a possible change in behavior in
`CallAndReferenceGenerator.applyCallArguments`, which however doesn't
seem to break anything: IrPropertyReferenceImpl can now also be handled
by this method.
FqName/FqNameUnsafe tend to eagerly compute things like
safe/parent/shortName which take a lot of space.
This change helps to lower strongly reachable memory just before codegen
in JVM IR by about 5% on a relatively big project.
A mechanism that allows kotlinx.serialization plugin to preserve the
correct (program) order of properties after serializing/deserializing
descriptors to kotlin metadata, which is needed for correct and stable
json serialization of class hierarchies in incremental/multi-module scenario.
It uses protobuf extensions.
Currently DescriptorByIdSignatureFinder performs lookup of descriptor
not only in the given module but also in its dependencies.
This behaviour is incorrect if we have some kind of
relation (e.g. mapping) between moduleDescriptor and found descriptor.
Thus, we add a handle to control search scope.
- Introduce Ir-based Functional interface factory
- Switch from LazyIr to pure
- Use kotlin library to access raw bytes
- Link dirty files against IC cache and dependencies instead of LazyIr
- Move `DescriptorByIdSignatureFinder` from K/N to common
- Support inline-bodies only MODE
Alexander Udalov