The `ConcurrentCollectionFactory` class was moved to the module
which is no longer available in the 213 platform distribution
`MapMaker().weakKeys().makeMap()` is used as drop-in replacement of
concurrent hash map with identity-based equals strategy
The new implementation stores keys on weak references, which should not
change the behavior of the `ModuleFileCacheImpl`.
1. If someone still has a strong reference to the `ktFile`, then the
cache will also keep it.
2. If there are no more strong references to the `ktFile`, then the
cache will not hold it from being garbage-collected. However, since
nobody has a strong reference to the `ktFile` anymore, nobody can call
`fileCached` or `getCachedFirFile` with it, and it will never be
requested from the cache.
KTI-1114
As there is no accurate way to figure out exact dependencies for each
library JAR, all project libraries but the current one are added as
dependencies. However, for performance reasons, each library is not
treated as an individual 'LLFirLibrarySession', instead a scope-based
'JvmClassFileBasedSymbolProvider' is used.
Although code analysis is correct with this setup, navigation between
libraries was broken. The reason is that source declarations were only
queried inside the library itself.
After the fix, declarations are first queried in the library,
and if there are no good candidates, all other libraries are scanned.
The same way things work in the Java plugin.
^KTIJ-23073 Fixed
For CallKind.VariableAccess, the condition when to *skip* resolution of
objects was previously collector.isSuccess. This wasn't strict enough
because collector.isSuccess could be true when the best found candidate
has an applicability like RESOLVED_WITH_LOW_PRIORITY (e.g. from dynamic
scope or annotated with @LowPriorityInOverloadResolution). In these
cases, we do want to resolve objects. To fix this, the condition is
changed to collector.shouldStopResolve which is stricter.
#KT-57960 Fixed
Original AbstractFirSpecificAnnotationResolveTransformer can jump
to other classes and resolve them outside
our transformers, so it leads to
problems with locks and lazy bodies
^KT-56543
We cannot do it inplace now as we do not have a lock to do
it under after analysis started to use declaration-level lock
This part is mostly covered by the plugin tests
(which failed after the previous commit)
^KT-56543
The change is needed for the parallel resolution (^KT-55750), so we can resolve the declaration
under a lock that is specific to this declaration.
Previously, if LL FIR was resolving some FirClass, LL FIR resolved all its children too, and it had no control over what parts of the FIR tree were modified.
The same applied to the designation path, sometimes the classes on the designation path
might be unexpectedly (and without lock) modified.
This commit introduces LLFirResolveTarget, which specifies which exact declarations should be resolved during the lazy resolution of the declaration.
All elements outside the declarations specified for resolve in LLFirResolveTarget, should not be modified.
The logic of lazy transformers is the following:
- Go to target declaration collecting all scopes from the file and containing classes
- Resolve only declarations that are specified by the LLFirResolveTarget, performing the resolve under a separate lock for each declaration
^KT-56543
^KT-57619 Fixed
The problem appeared because not all of the `realOverridden` have been
collected because inside AbstractSerializableListDecorator some of the
scopes returned the same instance as direct overridden and after that
overridden tree traversal stopped without detecting real overrides.
Thus, the modality of intersection for
AbstractSerializableListDecorator::size and MutableSet::size
was incorrectly computed to ABSTRACT
The similar thing is already done at the place where we're obtaining
all overrides.
See https://github.com/JetBrains/kotlin/commit/c80cfb0fdb00323ba9b5e1dd98c5cbd0bfab6b8b#diff-182d90c9b8050557e4e2eb319a84b9a51fd0600c728dd0fce85cf6491c13e16dR152
^KT-57693 Fixed
Meta issue: KT-8575
^KT-58061 Fixed
Review: https://jetbrains.team/p/kt/reviews/9677
This commit fixes an inconsistency between
FirUnsupportedSyntheticCallableReferenceChecker and
UnsupportedSyntheticCallableReferenceChecker
In K1 such properties were not considered synthetic and are called
JavaPropertyDescriptor. That's why we need to do an additional check in
K2 checker, while in K1 we didn't need to do it
Also see the previous commit for more related tests that already was
green without this fix but are related to KT-58061 problem
Review: https://jetbrains.team/p/kt/reviews/9677
I'm going to fix KT-58061 in the next commit. Firstly, let's cover
FirUnsupportedSyntheticCallableReferenceChecker with more tests that
already pass, but are related to KT-58061 problem.
Other related tests:
- testGenericJavaProperty
- testFunInterfaceConstructorReference
Meta issue: KT-8575
Review: https://jetbrains.team/p/kt/reviews/9595
UnsupportedSyntheticCallableReferenceChecker only existed for K1,
because we wanted to release the feature for 1.9 and the feature should
have been working for K2 unconditionally. But since, we're postponing
the release until 2.1, we also need to port the checker from K1 to K2
Roman Golyshev