The expected format was Kotlin language version (e.g. `2.0`), however the actual passed values were Kotlin release versions (e.g. `2.0.0`)
^KT-65986 In Progress
This diagnostic is reported in rare situations when
StubTypeForBuilderInference is kept as a parameter type
of for loop or lambda. Before this commit, we had in K1
"Could not load module <error module>" from IrLinker instead.
Related to: KT-52757, KT-53109, KT-63841, KT-64066
#KT-53478 Fixed
Usually we create synthetic property in java class if there is a property
from the base kotlin class and getter/setter with a corresponding name
in the declared scope or one of supertype scopes. But there is a case,
where the same supertype contains both property and getter:
```
// FILE: Base.kt
open class Base {
open val b = "O"
@JvmName("getBJava")
fun getB() : String = "K"
}
// FILE: Derived.java
public class Derived extends Base {}
```
In this case we shouldn't create synthetic property, because `getB()`
function is invisible for `Derived` class
^KT-66020 Fixed
- The fix uses relevant logic from `getNonLocalContainingDeclaration`.
- The annotation entry case is covered by `KtCallElement` because
`KtAnnotationEntry` is a subtype of it.
- KT-66038 is fixed by this because the static declaration provider only
indexes non-local classes.
^KT-66038 fixed
In K1, code fragment analysis was completely invalidated on any PSI
change. Because imports are not a part of the PSI tree of
'KtCodeFragment's, a colon tremble happened on 'addImportsFromString()'.
In K2, changes inside code fragments are always considered in-body
modifications. So, even with the colon trembling, the 'FirFile',
together with its 'FirImport's was not recreated.
^KT-65600 Fixed
Create dependency provider able to resolve code from .knm metadata
files to simplify migration from the legacy kotlin-stdlib-common
artifact.
KTIJ-28668
KTI-1457
In short, the problem is some
platform libraries contain invalid
Kotlin code. Specifically,
some classes may inherit multiple
members with default
implementations, but do not define
an explicit override, like `UIView.bounds`.
Since we can't refactor platrofm
libraries just now, we want to
treat such properties as abstract.
^KT-65866 Fixed
^KT-65855
... when the expected type is not a function type.
Instead set it to a new type variable.
This fixes a bunch of false negative CANNOT_INFER_PARAMETER_TYPE.
#KT-59882 Fixed
This commit adds code to check whether a deserialized cone type is a
special function type kind or not when resolving the type of a lambda
expression (anonymous function). If it is a special function kind, it
sets the type of lambda based on the special function kind.
^KT-64994 Fixed
Generally the wrapping anonymous initializer can be used as a
"containing declaration" for some elements, but since the initialiser
for the last script expression could be dropped (the expression could
be converted to the result property), this may lead to the surprises,
e.g. as described in KT-65984
This fix marks the last initialiser as local, preventing it from being
referenced as "containing declaration".
#KT-65984
The problem was that in K2 for some top-level script declarations we
need to add a dispatch receiver parameter (because frontend do not
assign any, but representing script as a class requires it to be the
script class) and at the same time, calls to these declarations rely on
properly set dispatch receiver parameter.
The simplest solution found is to have an additional traversal on the
relevan top-level declarations and assigning the dispatch receiver,
before running the main transformation.
#KT-64502 fixed
namely, add them to importing scopes directly and according to the
schema used for other implicit imports, rather than adding them
to the regular script file imports. See KT-65982 for explanation.
#KT-65982 fixed
The base class in scripting considered obsolete and therefore supported
via some ad-hoc mechanisms. In particular parameters to the base class
c-tor are passed via script provided properties. But in combination
with the resolution logic, this leads to issues described in KT-60452
This commits filters out such parameters from script resolution
scope and avoids this problem for now.
Bot it should be noted that proper diagnostics for properties shadowing
should still be implemented - see #KT-65809
#KT-60452 fixed
Andrei Tyrin