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
Current implementation checks only immediate supertype, while
in case of gradle build scripts DSL, the annotated superclass
is located deeper in the hierarchy.
The fix implements a recursive supertype check.
#KT-65983 fixed
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
`IrProvider`s are used to bind unbound symbols which are left after IR
construction. fir2ir doesn't leave any unbound symbols in the tree,
so there is actually no need in FirIrProvider at all