Given the strict pattern-matching in the inliner, this is the only way
to make it not crash when attempting to inline these stubs. Note that
the IR backend does not currently use the inliner's default method stub
handling; the crash only occurs when a module compiled with the non-IR
JVM backend is attempting to call an inline function with default
arguments defined in a module that was compiled with the IR backend.
NOTE: jvmCrossinlineLambdaDeclarationSite.kt is muted because the
inliner does not remap references to an anonymous object's parent
class after regenerating it. Unlike the JVM backend, JVM_IR uses the
top level named class' assertion status for all inner classes. (The
test used to pass because the lambda in `inline fun call` read the
`$assertionsDisabled` field of `CrossinlineLambdaContainer`, which
was not reloaded after changing the assertion status of package `test`.)
This commit:
- introduces tests explicating what is and isn't considered a
proper main method on the JVM backends.
- implements support for parameterless main methods on the JVM IR
backend
- See KT-34338 for more tests.
If the delegated property operators involved are inline, and delegated
property metadata parameter is not used (which is often the case, e.g.,
'lazy'), we can skip those properties in metadata generation.
NOT implemented: special case when only 'kProperty.name' is used by the
corresponding delegated property operators.
Also a sneak fix for KT-34060.
Avoid using a separate origin for temporary variables introduced
for for loops. That doesn't add anything and gives one more case
for optimizations to deal with.
Extend the JVM specific optimizations to remove temporary
variables to deal with more cases encountered in for loops
lowering.
Use the class of the subtype of CharSequence when available. When
it is not (for type parameters bounded by CharSequence) call the
CharSequence getter and 'get' method. Using the most specific type
posible fixes the forInStringSpecialized test that expects the
use of INVOKEVIRTUAL and not INVOKEINTERFACE.
Add tests for the type parameter use.
Similarly to previous commit, this method was unused since its
introduction before 1.0, so we're changing its semantics to throw NPE
and starting to use it with API version >= 1.4.
#KT-22275 In Progress
This method was introduced in c204e8fc67 "just in case" and was never
used. Therefore we're free to change its semantics and use it in all new
generated code (with API version >= 1.4), without even worrying that the
newly used API will leak from inline functions in stdlib when used with
an older API version. Since we agreed to change the type of thrown
exceptions to java.lang.NPE in KT-22275, invoke a new method
throwJavaNpe now which throws that exception instead of KNPE.
Note that the additional method that takes an exception message is still
unused and exists just in case we need to use it in the future. The new
method throwJavaNpe is public also "just in case" we need to invoke it
in the future; currently it's not invoked from the bytecode.
#KT-22275 In Progress
Without the `-Xmultifile-parts-inherit` mode for now.
This is implemented as follows: FileClassLowering collects information
about multifile parts and the corresponding facades, which a later
GenerateMultifileFacades phase uses to generate new IrFile instances and
add it to the module fragment that's being compiled.
Note that GenerateMultifileFacades is in the end of lowering phases
because delegates in the facade should be generated for all additional
functions generated by certain lowerings (default arguments,
JvmOverloads, etc.). If GenerateMultifileFacades was right after
FileClassLowering, they would still be generated, but we'd then process
them in lowerings mentioned above, which would result in duplicated
logic in the bytecode. There's a new bytecode text test which checks
that this doesn't happen for functions with default arguments.
