They started failing once we began reporting diagnostics from completion
The main reason is that we resolve `delegate()` call
from `delegate().getValue()` in the independent context, while in FE 1.0
it's being resolved within the same system as getValue
^KT-46420 Relates
Prefer to have all module dependencies, including dependencies on
stdlib/reflect, declared explicitly. This allows to have tests on
situations like the one in KT-45308: three modules A<-B<-C, where C
doesn't depend on A, which was compiling correctly with the old JVM
backend before 1.5, but started to fail with JVM IR in 1.5.
Also simplify the code a bit, remove duplicated logic.
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.
Denis.Zharkov