Before this commit, we copied each type parameter during method
enhancement, while not copying the symbol. This led to symbol clashes
in MPP scenarios and various other problems.
Now we create a fully-functional type parameter copy in enhancement
and perform a substitution of old type parameters with new ones
in receiver type, value parameter types, return type,
and type parameter upper bounds.
#KT-59766 Fixed
#KT-59738 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
NB: In general, it's unclear what to do in cases
like the following one, even when sometimes
we could, indeed, prefer something:
```
fun foo(a: Int, b: String, c: Boolean)
fun foo(b: String, c: Boolean, a: Int)
foo(c = false, b = "", a = 0)
```
^KT-55933 Fixed
This is needed for providing types for '_DebugLabel' variables in
code fragments. Originally, there come a JVM type descriptor, so there
it's converted to a FirResolvedTypeRef reference through FirJavaTypeRef.
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
This is needed because of mutable nature of receiver values: implicit
receiver values can be modified because of smartcasts, but in candidate
we need to store snapshot of receiver in the form it was at the beginning
of the resolution
^KT-58823 Fixed
KtResolveExtensions are designed to handle IDE analysis use cases where
source might not be available at analysis time, because that source is
generated by an external source generator, such as an annotation
processor or resource compiler. The sources generated by those external
generators can appear in the analysis scope, and cause issues with
source clash - resolution may find the virtual source from the
KtResolveExtension, the on-disk generated source from the external
generator, or both. This can cause issues, because that on-disk
generated source may be stale, and may not have symbols that will exist
the next time the generator is run (or, conversely, may have symbols
that will disappear on the next build).
To solve this, add a `getShadowedScope(): GlobalSearchScope` to
`KtResolveExtension`. Any files in the module that are included in that
scope will be hidden from resolution, allowing the resolve extension to
cleanly replace those files.
^KT-58834 fixed
- In LL FIR, we have increasingly formalized symbol name caches as
palpable objects. The main reasons for this formalization were the
need to share implementations of caching between different (LL FIR)
symbol providers, the need to build composite name caches from
individual name caches, and the introduction of resolve extensions
which may provide additional declarations and thus complicate the name
set construction for Kotlin symbol providers in LL FIR.
- `LLFirSymbolProviderNameCache` also shared a lot of similarities with
cache handling in FIR providers like
`FirCachingCompositeSymbolProvider` and
`AbstractFirDeserializedSymbolProvider`.
- This commit introduces a `FirSymbolNamesProvider` as a component of
`FirSymbolProvider`. This symbol names provider's task is to provide
the sets of names which `FirSymbolProvider` previously provided. It
also allows sharing implementations of `mayHaveTopLevel*` once and for
all, which is an improvement over the previously scattered
implementations (the same ideas replicated many times throughout
different symbol providers).
- `FirSymbolNamesProvider` by design doesn't cache, as many symbol
providers may not need such a cache. `FirCachedSymbolNamesProvider`
can be used to cache symbol names if needed. The symbol name provider
architecture also makes it easier to switch between caching and
non-caching, without the need to reimplement caches every time.
- Synthetic function types complicate the picture, but this complication
is now exposed with the rest of the API, instead of being hidden in a
few implementations here and there. This allows symbol providers to
more explicitly state whether they can provide generated function
types, which is an advantage for the correctness of composite symbol
providers.
Some specific notes:
- In `FirSyntheticFunctionInterfaceProviderBase`, the class ID check has
been replaced with a full `mayHaveTopLevelClassifier` check so that
the cache doesn't get filled with `null` entries.
- `LLFirKotlinSymbolProviderNameCache` is turned into a non-caching
`LLFirKotlinSymbolNamesProvider` so that this symbol names provider
and those of resolve extensions can be composed into one caching
symbol provider in `LLFirProviderHelper` without creating layers of
caches. If the Kotlin symbol names provider was caching out of the
box, `LLFirProviderHelper.symbolNameCache` would cache the
names (1) in the combined symbol names cache and (2) in the Kotlin
symbol names cache.
- A caching Kotlin symbol names cache can still be created easily with
the `LLFirKotlinSymbolNamesProvider.cached` constructor function.
JvmMappedScope.Signatures became mostly irrelevant and only
"useful" for checking if we really need to have the scope mapped
Now, the check is rewritten according to K1 semantics
^KT-57694 Fixed
This change is both makes code more consistent with K1 version
and fixes some issues introduced by previous changes
Before this fix, the test
FirPsiOldFrontendDiagnosticsTestGenerated$Tests$Modifiers$Const.testKCallable_after
was failing
^KT-57694 In Progress
Earlier, it wasn't really important but after the previous commit
when JvmMappedScope semantics has been changed, we erroneously
started loading `toCharArray` as a member to String because
its jvmDescriptor was computed to "toCharArray()Lkotlin/CharArray",
while hardcoded information that prevents it from loading expect
"toCharArray()[C" there.
^KT-57694 In progress
Previously, the semantic was more-or-less correct for most of the cases
but some corner one, like `sort` in MutableList didn't work properly.
Namely, `sort` should be marked there in a way to forbid to call it
everywhere beside super-calls.
Also, overriding it should be allowed.
Mostly, the logic was re-written to K2 model from K1-related
JvmBuiltInsCustomizer.
^KT-57694 In progress
^KT-57269 Fixed
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
This commit adds missing pieces for the puzzle:
Annotation instantiation feature uses IrProperty's initializer to instantiate
properties from other modules that have default values which weren't
specified on call site.
To support this feature properly, Fir2IrVisitor should fill LazyIrProperty's
backing field initializer with information from Fir.
To get this information into Fir, FirMemberDeserializer should be able to read
it from KotlinJvmBinaryClass with AnnotationLoaderVisitorImpl. (klibs are unsupported for now)
There's a catch with enum entries references: we can't access session.SymbolProvider to resolve it
because we're still at the deserialization stage, and it can cause StackOverflow if enum is nested in the
same class (see RequiresOptIn.Level). To mitigate this, a new FirEnumEntryDeserializedAccessExpression is produced
instead; it is later replaced with the correct reference in the Fir2IrVisitor.
^KT-58137 Fixed
Also add test to loadJava folder with annotations default values that
verifies metadata loading
JavaClassUseSiteMemberScope won't return a Java method getFoo if there
is an inherited Kotlin property foo in scope because calling this method
would effectively call the property accessor which is not possible in
Kotlin.
This commit excludes private properties from this consideration because
no accessor methods are generated for them, and so calling a Java method
getFoo is ok.
#KT-58577 Fixed
Previously, when a candidate was found with an applicability that is
better than the current best applicability, all previous candidates were
thrown away. Now we keep them, unless the new applicability is
successful. If no successful candidates are found, we fully resolve all
the unsuccessful ones and select the ones with the least bad
applicability. This improves diagnostics for unresolved calls.
#KT-57844 Fixed
The previous implementation had issues with
locks, publication and performance
Also, this change fixed a problem with mixed cycle inheritance
^KT-56550
^KTIJ-25430 Fixed
^KTIJ-23520 Fixed
^KT-57623 Fixed
^KTIJ-25372 Fixed
^KT-58357 Fixed
^KTIJ-24638
Notice on `DebugSymbolRenderer`:
stub based deserializer sets source directly,
but it's available in IDE mode only.
Thus, standalone and IDE tests have different results.
In order to avoid this, sources for compiled code are explicitly ignored
Notice on distinct callables:
for a file which belong to multiple libraries, decompiled code would be build per library.
In order to avoid ambiguity errors for members in that file,
we need to distinct provided elements by origins
failed test from IJ repo:
FirReferenceResolveWithCrossLibTestGenerated#testSetWithTypeParameters
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
- `LLFirCombinedJavaSymbolProvider` combines multiple
`JavaSymbolProvider`s. Its advantages are: combined index access,
caching, classpath order disambiguation.
- Scopes can still be optimized with a combined scope instead of a naive
union scope.
^KT-57207 fixed
- `javaFacade.findClass` is a potentially costly operation. This commit
extends `JavaSymbolProvider` and its class cache to accept an already
existing `JavaClass` if provided, circumventing the `findClass`
operation.
- `FirJavaFacade.knownClassNamesInPackage` cannot be computed in the IDE
using the current strategy because there are multiple finders and
there is no `CliFinder`. However, the cache was still used, which
caused it to be filled with `null` values and additionally caused
worse performance in `JavaSymbolProvider` due to hash map accesses via
`hasTopLevelClassOf`.
- Rewriting the strategy is non-trivial as additional indices are needed
on the IDE side. See KTIJ-24642.
The only case when behavior is change is described at
computeNonTrivialTypeArgumentForScopeSubstitutor
The idea is to avoid depending on the presence of @UnsafeVariance
and instead approximate captured types in covariant argument positions
before building substitution scopes
It's correct because for Captured(*) <: Supertype,
Out<Captured(*)> <: Out<Supertype> and when we've got @UnsafeVariance
value parameters at Out, it's ok to allow passing Supertype there.
^KT-57602 Fixed
^KT-54894 Fixed
- An `OptionalAnnotationClassesProvider` only needs to be created if the
package part provider may even have optional annotation classes.
- In the IDE case, the package part provider never provides optional
annotation classes, so especially in the IDE, we can avoid a lot of
useless symbol providers with this.
In a lot of cases, when we want to process the
declaration in scope, it should be resolved to at least TYPES phase.
To avoid doing it manually in all our variety of scopes, we do it when the scope it created.
It was implicitly working manually before as lazy resolve did a lot of extra work
on resolving a declaration it was not supposed to resolve.
Now it's not the case, and we have to explicitly resolve all the declarations we need.
^KT-56543
Co-authored-by: Ilya Kirillov <ilya.kirillov@jetbrains.com>
so the check is functionally the same as in K1.
#KT-57064 fixed
#KT-57065 fixed
One of the tests introduced here (javaMappedCtors) revealed an
additional issue, filed as KT-57368
Dmitrii Gridin