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.
This was missing for IrFunctionReferences, which caused problems when
copying default parameters before CallableReferenceLowering in the
JVM_IR backend.
They are currently marked as defined even when they get a
default implementation. That makes it hard to figure out
if the accessor should be removed when introducing a backing
field in the JVM_IR backend.
Instead of calling enormously complicated
KotlinTypeMapper.mapToCallableMethod, where most of special cases are
handled in the IR backend via lowerings.
Any access to a function from a multi-file part needs to be replaced
with the access to the corresponding public method (if it exists) from
the facade class. Note that this has no immediate effect because we use
KotlinTypeMapper for mapping calls, and it understands that a call to a
function from the part must actually be generated into a call to the
function from the facade in the bytecode. This commit merely changes the
IR to better reflect what's generated in the final bytecode, and to be
able to use simplified IR-based method signature mapping instead of the
legacy KotlinTypeMapper in the future.
There are two parts in this change:
1) Previously, we looked up $default methods with the incorrect
signature in supertypes. For example in defaultInSuperClass.kt, we'd
try to find a method foo$default with the signature `(B, String,
String, int, Object)` in the class A. Now we're modifying the array
of parameter types on each step if we're looking for a static
$default method, by assigning its first element to be the containing
class. This fixes cases when defaults come from a superclass.
2) For interfaces, $default methods are actually located in the
corresponding DefaultImpls class. Now we look up that class and
search for the $default method there. Note that this is needed
because of KT-33430. This fixes cases when defaults come from a
superinterface.
#KT-13936 Fixed
Note: this currently results in invalid IR (but valid bytecode) if the
@JvmStatic function is imported, because its IR representation is
unlowered and therefore has a dispatch receiver, but the call will not.
Ilmir Usmanov