Special getter names (like Collection.size()) can be used only in Java
classes with all-java super-types
Because if there is a kotlin class (not interface) in
the middle, we 'materialize' special getters to properties.
This will be used at least in the JVM backend instead of the current
approach where we're loading the primary constructor's first parameter,
which isn't good enough since primary constructor can be private, and
we can't rely on private declarations in case they're declared in
another module.
For subclasses of `AbstractMutableList<Int>` which are not inline
classes, the special bridge `remove` had a parameter of type `Int`
(mapped to JVM primitive int) before this fix. The hack in
`MethodSignatureMapper` changed this type to `Int?`, yet the body of the
special bridge still loaded it as non-nullable, which resulted in
incorrect bytecode.
It looks like a part of this hack in `BridgeLowering` was made only for
inline classes which are subclasses of mutable collections. Supposedly
it should be extended to non-inline classes, so that `remove` special
bridge would have consistent IR by the time it reaches codegen.
#KT-46516 Fixed
FunctionNVarargBridgeLowering checked the name of the method instead
of whether the method overrides an invoke method. That doesn't work
when the name of the function gets mangled because of inline class
arguments.
Fixed KT-45084.
This allows taking function references to inline array constructors.
Also, redundant classes are no longer generated when function references
are passed as arguments to the array constructors.
#KT-46426 Fixed
For code such as:
```
try {
var y = "y"
for (i in 0 until 1) {
return y
}
} finally {
println("finally")
}
```
The local variables `y` and `i` ended up covering the finally block as
well in the debugger.
This change splits the range of the locals so that they do
not cover the finally block.
This change does not change the inliner to do similar transformations,
so the range of locals is still wrong win finally blocks when inlined
into an inline function. Added a failing test to that effect.
Recursive results from checkForPrimitiveOrPattern were ignored. If it found a case/condition that could not be optimized the resulting "false" was not propagated. This would lead to a "optimized" when without all conditions.
- see KT-45738
- The return is now lifted out of the when to make it more obvious what is going on.
- New test for mixed multiple conditions in when
pyos