In case of partial/incremental compilation, a module usually consists of
two roots, one of which is source and another is binary. Thus, it's
incorrect to divide modules into "binary" and "non-binary", and only
look for .class files in "binary" modules in
CliJavaModuleResolver.findJavaModule. The more correct way is to think
of a module as a collection of roots, and every root is either binary or
source
If there is default qualifier with TYPE_USE closer than one with METHOD
then its nullability should be considered even when enhancing return type
#KT-20016 Fixed
This function is now used instead of allImplementingCompatibleModules,
thus allowing it to be deleted together with allImplementingModules
So #KT-17369 Fixed
So #KT-17374 Fixed
May fix also some other MPP issues
Synthetic accessor for 'setValue' was generated incorrectly,
specific case of KT-20491 (Incorrect synthetic accessor generated for a
generic base class function specialized with primitive type).
Make sure there's no equivalent of KT-20387 for delegated properties.
When generating collection element receiver (such as 'a[i]'), accessible
descriptor for get/set operator should be used.
Otherwise, if the corresponding get/set operator fun is called via an
accessor, its argument types may be different in case of generic fun
specialized with primitive types.
#KT-20387 Fixed
Accessor parameter types may be different from callee parameter types
in case of generic methods specialized by primitive types:
open class Base<T> {
protected fun foo(x: T) {}
}
// in different package
class Derived : Base<Long> {
inner class Inner {
fun bar() { foo(42L) }
}
}
Synthetic accessor for 'Base.foo' in 'Derived' has signature '(J)V'
(not '(Ljava.lang.Object;)V' or '(Ljava.lang.Long;)V'),
and should box its parameter.
Note that in Java the corresponding synthetic accessor has signature
'(Ljava.lang.Long;)V' with auto-boxing at call site.
#KT-20491 Fixed
The important changes are in ideaTestUtils.kt:
`configureByFiles` must be called on the relative to testData dir path,
otherwise java files in the project belong to src/idea/testData/.../A.java
instead of src/A.java and can't be found in the root package
New updates in resolution when resolving A() call is now asking whether
<root>.A exists in PsiPackage::getClasses instead of
PsiPackage::findClassByShortName that can find a class even if it's located
in the wrong directory
Its main purpose is code simplification: ImplicitScopeTower::run
contains a lot of local functions that are needed because of
lots of shared state
So, we're moving the state to the Task class instead
NB: This change doesn't change the code of `run`, it will be done
in further commits
Denis Zharkov