Keeping the origin as LOCAL_FUNCTION_FOR_LAMBDA was a mistake as this
tells codegen nothing. Changing the origin in allows, for example,
removing the hack that detaches inline lambdas from the IR tree before
verification and codegen, or treating inline lambdas and inline
anonymous functions the same way.
This includes fake functions created for inline callable references.
#KT-48319 Fixed
#KT-47279 Fixed?
ProhibitAssigningSingleElementsToVarargsInNamedForm is enabled from 1.3
so there is no need to make FIR accepting single element passed through
named arguments.
In addition, we may want to report only
ASSIGNING_SINGLE_ELEMENT_TO_VARARG_IN_NAMED_FORM_FUNCTION and not arg
type mismatch. But FE1.0 is reporting both so I am following it. If we
want to remove the redundant report, we will probably want to remove
FirNamedVarargChecker and report during resolution as a cone diagnostic.
Difference from FE1.0
* KT-4285: calls to virtual method with default argument should be
reported as not tailrec. FE1.0 is missing such cases.
* KT-48600: calls inside lambda should be reported as not tailrec. FE1.0
also misses such cases.
Their call sites are all in the same file, so we can check whether the
declarations used in the inline function are accessible from all the
places where it will be inlined.
#KT-48736 Fixed
While annotations restrict the set of allowed types to a few final
built-ins, in arbitrary constants we can have array elements that are
some subtype of the array's element type.
#KT-48671 Fixed
- Materialize unit when its value is actually needed.
- Special-case Unit_getInstance return type at codegen. It should be a
proper Unit object instead of a "void"
We can't apply "reuse loop variable as index variable" transformation
before local declarations lowering, otherwise it will affect captured
loop variable behavior, resulting in KT-48626.
Since it's JVM-specific, move it to JvmOptimizationLowering.
The condition on the relationship between the current class and the type
of the receiver for protected members was the opposite of what the JVMS
says, and yet somehow mostly worked?
#KT-48331 Fixed
#KT-20542 Fixed
Descriptors are already supposed to be sorted in scopes. The problem is
that rendering descriptors for sorting takes a lot of time (~1.5% of
total compilation time of intellij with JVM IR), and simple heuristics,
like comparing by names first, don't fully help with it.
#KT-48233
It is not correct to assume that arg0 has been generated to have the
same IrType as the whole expression.
The reason it only backfired in throwing exceptions probably has to do
with the fact that visitThrow might be the only place in
ExpressionCodegen right now which uses the IrType from PromisedValue to
make a decision on whether to generate checkcast.
It seems suspicious that ExpressionCodegen.visitFieldAccess/visitCall
return PromisedValue whose IrType mentions type parameters which are
declared outside of the call site, but that should probably be
investigated separately.
#KT-48440 Fixed
Generate $delegate method as instance method in
PropertyReferenceDelegationLowering, and remove dispatch receiver later
in MakePropertyDelegateMethodsStatic. The method needs to be static to
be non-overridable (see delegateMethodIsNonOverridable.kt), and public
to be accessible in reflection.
Otherwise we generated incorrect IR where a static function accessed an
instance field of the containing class, which failed in multiple places
including LocalDeclarationsLowering.
#KT-48350 Fixed
Given inline class V(Any?), a coercion from (Object, V) to (Object, V?)
is boxing.
In theory, the same issue in the old backend can be fixed by making
`KotlinTypeMapper.mapUnderlyingTypeOfInlineClassType` use
`computeExpandedTypeForInlineClass`, but for some reason this breaks a
lot of stuff.
#KT-48430 Fixed
This is already the case for straightline code such as
```
inline fun <R> f(size: Int, block: () -> R): R {
var result: R
result = block()
return result
}
```
However, if the local variable introduction happens at a merge
point as in the following example, we allow the unboxing but
only do it halfway. The initialization of the local is still
done with a null value.
```
inline fun <R> f(size: Int, block: () -> R): R {
var result: R
while (true) {
result = block()
if (size == 0) break
}
return result
}
```
This change disallows unboxing for this move complicated
case as well by bailing out if a local use is with a
TaintedBoxedValue (merge of Object and Integer).
^KT-48394 Fixed.
pyos