Before this commit, we generated fake overrides at last FIR2IR stage,
after having all functions and classes built. This could lead to a
situation when fake override was called before it was generated.
This commit fixes this situation.
In 1.3.x, for inline class member inline vals 'getFoo-impl' method was
generated in corresponding inline class.
Since 1.4.0, getters for properties returning inline class values are
mangled (so corresponding getters are named 'getFoo-<mangling_hash>'.
However, to maintain backward compatibility with libraries compiled with
1.3.x, inliner should be able to find 'getFoo-impl' method in the
bytecode.
...in class members. The corresponding classes end up nested in the
class initializer of the surrounding class and we need to take this into
account when creating instances of ClassCodegen.
This fixes KT-40332 on the JVM IR backend.
The main change here is that when kotlin-reflect is being run under Java
9+, we use another implementation of BuiltInsResourceLoader (see
libraries/reflect/api/src/java9) which loads .kotlin_builtins files from
the java.lang.Module instance of kotlin-stdlib, instead of the class
loader of kotlin-reflect, which may not have access to those resources.
If the application is being run in the old (classpath) mode, that Module
represents the unnamed module, which contains everything on the
classpath, and everything works as before. But if it's being run in the
modular mode, that Module instance is an encapsulated module for
kotlin-stdlib classes and resources, exactly where .kotlin_builtins
files are located.
This fixes a regression in 1.4.0. Prior to 1.4, kotlin-reflect and
kotlin-stdlib were not named modules (see KT-21266) and were loaded as
_automatic_ modules even if the application was run in the modular mode.
Apparently, they shared the same class loader in that case and looking
up .kotlin_builtins resources worked.
This change was supposed to go alongside
828cc6dbf3, but was overlooked because
adding module-info to standard libraries was postponed at that point.
Also slightly refactor Java9ModulesIntegrationTest to simplify running
compiled code, and add a smoke test on using kotlin-reflect in modular
mode.
#KT-40842 Fixed
JVM_IR has consistent stepping behavior for secondary constructors
and init blocks. This change fixes the expectations for tests that
expect the less consistent JVM backend behavior.
Temporary variable loads in when expressions had the offsets
of the variable declaration. That leads to hacks during codegen
for line number generation.
Instead of those hacks, give the variable loads the offsets of
the context in which they occur. That avoids the codegen hacks
and fixes stepping behavior for more when expressions.
NB some cases such as captured extension receiver for an extension
lambda are not supported yet; to be discussed, to what extent should we
actually follow JVM code shape here.
Mikhail Zarechenskiy