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
Now we will try to avoid redundant calculation:
* Class-like declarations can be calculated without super types
* Overridden search logic not is out of lock
Unfortunately, right now it is not safe to use
StatusResolveMode.FunctionWithSpecificName and
StatusResolveMode.PropertyWithSpecificName
because lazyResolveToPhaseWithCallableMembers can lead to an incorrect
state of scope. Example:
```
open class A {
open fun a() {}
open fun b() {}
}
class C : A()
```
Steps:
1. Resolve constructor of C to STATUS
2. Now we want to call lazyResolveToPhaseWithCallableMembers on
C, and this call will do nothing because this class and all
its declarations (only constructor) are already in STATUS phase,
so class A won't be resolved as expected
^KT-56551
The problem was that type parameters of Java function were changed
without any synchronization.
In fact, we shouldn't mutate Java declarations at all.
So now we don't mutate type parameters – instead of this,
we mutate only its copy that is safe
^KT-58613 Fixed
^KTIJ-25242 Fixed
^KTIJ-21791 Fixed
The key 'localDeclarationsData' is a IrFunction whose symbol owner is 'IrDeclarationOrigin.LOCAL_FUNCTION'. To find the 'localsData', it's required to get the original local IrFunction ('IrDeclarationOrigin.LOCAL_FUNCTION') for the IrFunction with default arguments (IrDeclarationOrigin.FUNCTION_FOR_DEFAULT_PARAMETER).
Related to KTIJ-25558
Previously, we did the kotlin subclasses name search two times:
- via `KotlinDeclarationProvider`
- via `JavaElementFinder`
which is redundant and slows down the searching
This is needed for the cases when a candidate name set is known
to avoid retrieving a set with all possible names when processing the scope.
Similar to KtScope.
^KT-58653
This is needed for the cases when a candidate name set is known
to avoid retrieving a set with all possible names when processing the scope.
^KT-58653 fixed
Nikolay Lunyak