From user point of view it's an improvement in compilation message.
From technical point of view it's an introduction of new compilation
diagnostic.
Review: https://jetbrains.team/p/kt/reviews/9967
I'm going to deprecate `open val` case in the next few commits KT-57553.
But it is always possible to suggest using `final` for `open val` case.
^KT-58346 Fixed
Review: https://jetbrains.team/p/kt/reviews/9967
BTW this commit accidentaly and partially fixes KT-57553 for K2, because
of a cleaner K2 architecture. I will unify MUST_BE_INITIALIZED behaviour
in K1 and K2 in the next commits
Review: https://jetbrains.team/p/kt/reviews/9967
I'm going to change the logic in this area in the next few commits
KT-57553. So let's cover the current behaviour with tests.
*.fir.kt tests are not properly formatted because of K1 and K2 different
behaviour. I will fix it in the next commits
Recommend users default `project.dependencies` instead.
Gradle's DependencyHanlder has its own evolution thus
we cannot easily maintain API of KotlinDependencyHandler to look like
Gradle's DependencyHandler. We're going to support only our own
factory methods to create dependencies + `project` dependencies.
KT-58759 Verification Pending
- Mangled names of property accessors now include context receiver
types of the corresponding property when computed from FIR.
- Context receivers are now supported when computing mangled names
from IR
- IrBasedDescriptors now account for context receivers
^KT-57435 Fixed
After it's released, there would be no need in them, but right now
they are unavailable through the toolchain, so we can't require it.
See KT-58765 for tracking
But there should be a dedicated Build configuration with JDK_21_0 env
properly set.
^KT-58716 Fixed
Exception (even PCE) can lead to inconsistent situations, for example,
where a function can be marked as resolved, but arguments – not.
Also, in this case, it is possible that the function will be
marked as resolved to TYPES, but not all its type really resolved
^KTIJ-25582 Fixed
This commit removes the relevant feature from 1.9 and
makes this feature experimental.
We plan to enable it in some 2.* version (not earlier than 2.1)
Related to KT-54261, KT-36932, KT-49276
#KT-58791 Fixed
It is required for methods with default parameters to pass a dispatchReceiver (if the IrCall has one) as an argument, because the method generated bytecode expects it. In the case where the function has both receivers (dispatchReceiver and extensionReceiver), only the extensionReceiver should be added.
Related to KTIJ-24564
Nikita Bobko