Commonize (in terms of TypeSystemCommonBackendContext implementations
for KotlinType/IrType) code that computes optimal TypeMappingMode to
apply to different positions where inline class types can be present.
KotlinTypeMapper.mapInlineClassTypeAsDeclaration and
mapUnderlyingTypeOfInlineClassType invoked mapType which is defined in
descriptorBasedTypeSignatureMapping.kt and works on KotlinType.
It didn't lead to any problems, other than the fact that we were
constructing IrBasedClassDescriptor in JVM IR, and then KotlinType to
pass it to mapType, on each call to StackValue.boxInlineClass or
unboxInlineClass, which seems wasteful.
Instead of this, refactor these utilities to use type markers instead,
pass IrType and IrTypeMapper directly from JVM IR, and move the "static
type mapper" logic (which is used only in the old backend) out of
KotlinTypeMapper.
For example,
```
do {
...
} while(
when (...) {
... -> break
}
)
```
That `break` condition is `when` expression, and while visiting its
branch result, we will see the same `break` again.
As shown in KT-44412 (or KT-45319 or KT-17728):
```
fun test5() {
var i = 0
Outer@while (true) {
++i
var j = 0
Inner@do {
++j
} while (if (j >= 3) false else break) // break@Inner
if (i == 3) break
}
}
```
To properly set the loop target for `break` in do-while loop condition,
the loop target for that do-while loop should be ready before parsing
the loop condition.
Previously, Raw FIR loop building configures loop target after visiting
loop conditions. This commit splits the configuration and lets the
builders prepare the loop target for do-while loop only.
By default copyable (IrExpressionWithCopy) declarations is considered as side-effects.
^KT-45655 fixed
[IR] isTrivial more robust
By default copyable (IrExpressionWithCopy) declarations is considered as trivials.
[IR] Use one source of truth for triviality of IrExpression
Deprecate specialized unsigned iterators for removal.
Fix compiler tests:
- drop unsignedLiteralsOn1_2 because apiVersion 1.2 is no longer supported
- drop experimental unsigned literals diagnostic test
This reverts commit 9934cfbb00.
See the tests added: Subclass may have private same-name method that
should not be a reason to avoid generating fake overrides
Protected functions on unrelated classes cannot be called from outside
the current package, so in general, we can only call the static proxy,
not the original companion method.
This has an ABI compatibility implication in that removing `@JvmStatic`
from a protected companion method will require recompiling Kotlin use
sites (of course, this is already source- and binary-incompatible from
Java perspective).
#KT-12063 Fixed
Because the receiver type is used for determining where to put
accessors, and the type of fake overrides' receivers is the same as for
the original declaration, casting to the type of the parameter leads to
assertion errors.
#KT-44658 Fixed
Mikhail Glukhikh