- 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
Configure consistent metadata resolution only for source sets that
participate in metadata compilation. i.e. test or any other extra
compilations should be excluded.
^KT-65954 Verification Pending
^KT-66047 Verification Pending
Source Set Visibility algorithm relies on the match between metadata
dependencies resolution and platform dependencies resolution. However
there is a chance that they don't match in versions.
i.e. commonMain resolved into 1.0 but jvmMain got 2.0 of the same
library. However this discrepancy is not correct after all. And
both metadata compilations and platform compilations should see the same
set of libraries. This behavior will be fixed in KT-66047
^KT-65954 Verification Pending
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
We want to test whether the propagation of function type kind annotation
correctly works or not. This commit updates
ComposableFunctionsTransformer that mimics the real compose compiler
plugin to propagate the composable annotation i.e., @MyComposable from
MyComposableFunction kind. Finally, the generated IR function for lambda
expression must have the composable annotation, when the lambda
expression does not have the explicit composable annotation, but we
infer the composable annotation based on the annotation of function type
for the value parameter.
^KT-64994
The test infrastructure for analysis supports binary module tests, but
the binary build does not use another binary module as a dependency when
it passes the class path. As a result, each binary module build does not
work when they have dependency on each other.
This commit fixes the issue by
1. Topological sort in the order of dependency graph for test modules.
2. Pass module paths as extra class paths when they have dependency on
each other.
^KT-64994
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
Marco Pennekamp