During subtyping/incorporation we transform types (e.g. changing nullability,
form of the type) and, basically, we're doing this to some FIXPOINT.
It's important that we use `KotlinType.hashCode()` to compare types, but
for error types hashCode is a hashCode of its supertype and, for example,
`makeNullableAsSpecified` method recreate type every time. So, we continue
to generate new constraints and we'll never stop incorporation algorithm
Supported:
- conversion in resolution parts. Also sam-with-receiver is supported automatically
- separate flag for kotlin function with java SAM as parameters
TODO:
- fix overload conflict error when function type is the same byte origin types is ordered
- consider case when parameter type is T, T <:> Runnable
- support vararg of Runnable
[NI] Turn off synthetic scope with SAM adapter functions if NI enabled
For almost all cases this change do nothing, because if parameter isn't
vararg, then both methods (FlatSignature.argumentValueType &
getExpectedType) return same value. Moreover if it is vararg parameter
and spread operator is not used, then results will be the same.
We can observe difference only when spread operator used
and when we compare two candidates corresponding parameters
for both spread arguments should be vararg parameters.
I.e. old way compares: Int vs String
new way compares: Array<out Int> vs Array<out String>.
MPP-related:
* inherited from interfaces
* inherited body from interface
* default arguments in an interface, implemented by a class delegate
* super call of a method with default argument
Also:
* inheritance from an interface and another interface descendant (KT-21968)
* inheritance through an intermediate interface
Usages of declarations annotated with WasExperimental are allowed even
if the API version requirement is not satisfied, provided that the
opt-in to all mentioned markers is given. This is needed for smooth
graduation of API in kotlin-stdlib
There was an exponential complexity in case we have a chain
of nested LexicalScopeWrapper instances:
we were walking through the chain and on each step running
the algorithm recursively.
Such a case is possible in scripts where each line contains LexicalScopeWrapper
The fix looks safe to me because delegate was used there
for checking !is ImportingScope && !is LexicalChainedScope
In all other means, being recursively run the algorithm does the same job.
#KT-22740 Fixed
When plugins DSL is used, there is no need to
manually generate typesafe accessors for extensions and
conventions (by running `./gradlew kotlinDslAccessorsSnapshot`).
Introdude deprecation as per KT-21515. Warning is reported on type
usage, that soon will became invisible. Quickfix by adding explicit
import is added.
Idea behind implementation is to mark scopes that are deprecated (see
ClassResolutionScopesSupport).
Then, during walk along hierarchy of scopes, look at deprecation status
of the scope that has provided this classifier.
Note that we also have to check if there are *some* non-deprecated
visibility paths (because we can see classifier by two paths, e.g. if
we've added explicit import) -- then this type reference shouldn't be
treated as deprecated.
When default argument value was present in the expected declaration, we
did not correctly serialize that fact to the metadata for the actual
declaration (`declaresDefaultValue` was used). Therefore, it was
impossible to use that actual declaration without passing all parameter
values in another module, where it was seen as a deserialized descriptor
#KT-21913
When a parameter has a default argument value both in the expected
annotation and in the actual annotation, they must be equal. This check
has been only implemented for the case when actual annotation is Kotlin
source code, and NOT a Java class coming from an actual typealias. The
latter case would require a bit more work in passing a platform-specific
annotation-value-reading component to ExpectedActualDeclarationChecker,
and is therefore postponed.
For now, Java annotations that are visible through actual type aliases
cannot have default argument values for parameters which already have
default values in the expected annotation declaration
#KT-22703 Fixed
#KT-22704 Open
The point is that it's placed in module 'resolution' where it can be
accessed for example in ArgumentsToParametersMapper to load default
argument values from expected function
Ilmir Usmanov