From `ConcurrentMap#compute`
>The entire method invocation is performed atomically.
>Some attempted update operations on this map by other threads may
>be blocked while computation is in progress, so the computation
>should be short and simple
And we can call resolution (`reanalyze()`) under this synchronized
block that can take unpredictable time.
This fix drops all heavy operations from synchronization
It is required to avoid leakage of annotations instance from
the original type
It should be enough to just create a new instance of an annotation
without a deep copy, because transformer shouldn't touch it
^KT-60387 Fixed
Currently, FirLegacyRawContractDescription is a valid class for
resolved contract in case of error description.
This condition should be dropped after KT-60310
^KT-60310
LLFirTypeTargetResolver in general is responsible for annotation
type resolution, so such checks should be done on its phase.
Also, there is no sense to trying to check a type of annotation mapping
values because they will be initialized only during
LLFirAnnotationArgumentsMappingTargetResolver so, in most cases,
current check during LLFirAnnotationArgumentsLazyResolver is useless
^KT-60295 Fixed
The fresh version of intellij has all record-related declarations,
so an additional fake constructor leads to errors like
KTIJ-25364 (OVERLOAD_RESOLUTION_AMBIGUITY)
^KTIJ-25366 Fixed
^KTIJ-25364 Fixed
^KTIJ-25368 Fixed
^KTIJ-25370 Fixed
Problem: fakeOverrideSubstitution was set to null before the return
type was published, so another thread can see a state where
fakeOverrideSubstitution is null and a return type is implicit
simultaneously
^KT-60385
^KT-59758 Fixed
Now we will resolve declarations only ones and to the
minimal required phase to get a fully resolved element
depends on an insert position, because not all elements
require body resolution
A side change: `getOnAirGetTowerContextProvider` now
won't do rebind to the original declaration. In the future,
this part will be rewritten to avoid on-air resolution,
so it is not a problem
^KT-59685 Fixed
Now we will invalidate bodies for FIR declarations
immediately after in-block modifications in these declarations
We assume that such in-block modifications can happen
only under write action,
so it should be safe to make changes for FirFile
^KT-59687 Fixed
^KT-59199 Fixed
^KTIJ-26066 Fixed
Treat changes inside non-top level property initializer as OOB
It is OOB because CFG for a class depends on a property initializer,
so we must rebuild CFG for the class
Also, this commit makes the API more understandable
^KT-59687
A designation path for synthetic declarations like fake override
or member delegate contained the wrong FirFile, because it
was provided by the original declaration that is wrong.
So we should pick up the file from our path, because it shouldn't be
synthetic
^KT-59505 Fixed
We can avoid body resolution in some cases because it is more
than out contract is required
So ANNOTATIONS_ARGUMENTS_MAPPING should be enough for all
non-body parts of a declaration to return fully-resolved FirElement
Body parts incudes: body and default values
^KT-59266 Fixed
To create a smart psi type pointer, IJ Platform uses resolve
We cannot use resolve from JavaSymbolProvider,
as it may lead to resolve contract violation
^KT-59243 Fixed
To create a smart psi type pointer, IJ Platform uses resolve
We cannot use resolve from JavaSymbolProvider,
as it may lead to resolve contract violation
^KT-59240 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
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
'forceSkipResolvedClasses' is wrong here, because nested class (`CC`)
won't be marked as cycle but the outer is.
Instead of this, we should check
canHaveLoopInSupertypesHierarchy recursively
```kotlin
open class C : <!CYCLIC_INHERITANCE_HIERARCHY!>D<!>() {
open class CC
}
open class D : <!CYCLIC_INHERITANCE_HIERARCHY!>C.CC<!>()
```
Also, this commit adds an optimization to avoid hierarchy search
for non-source classes (forceSkipResolvedClasses was introduced for this before)
Also, this change adds SinceKotlin and Java.Deprecated to this phase
It fixes some problems with API_NOT_AVAILABLE, so now it is closer to K1
^KT-57648 Fixed
^KT-55723 Fixed
Dmitrii Gridin