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
In that case, when loading Java, we just remember the name of `@Nonnull`
argument (javax.annotation.meta.When), and then use it during enhancement
^KT-56656 Fixed
- Some completion performance tests (e.g. IntelliJ: "empty place typing
with library cache") spent a considerable amount of time in
`KtFirSymbolProviderByJavaPsi.getNamedClassSymbol`.
- This commit introduces `KtFirPsiJavaClassSymbol`, which implements
many `KtNamedClassOrObjectSymbol` properties with the `PsiClass`
instead of the FIR class. The `FirClassSymbol` is built only when
necessary. This improves performance when no "slow" properties need to
be computed for the symbol.
^KT-56617 fixed
It's been introduced in the previous commit
("K2: Simplify handling mixed smartcast vs. original candidates")
Because previously, it was assumed wrongly that each next level of
ConeCallConflictResolver filter out the candidates that are 100% less
applicable/specific, but the main one (ConeOverloadConflictResolver)
either leaves the single candidate or the whole same set, thus at
FilteringOutOriginalInPresenceOfSmartCastConeCallConflictResolver
we've got 4 candidates only two of which we might filter out.
The idea is that when we have successful candidates both from smart cast
and original type, we should discriminate in the favor of former ones.
While this problem (see kt55722.kt) existed before this branch is merged,
initially it was recognized on FP Ultimate when we stopped assuming
captured types from the same projections as equal (see kt55722Initial.kt).
^KT-55722 Fixed
^KT-55024 Fixed
^KT-56283 Related
^KT-56310 Related
This flag is true by default but is set to false for
- Java methods and constructors
- interface delegation methods that delegate to Java
The NAMED_ARGUMENTS_NOT_ALLOWED logic is mostly refactored to use the
new flag though some custom logic remains for determining the correct
message and to work around a corner case with fake overrides.
The flag is (de)serialized from/to metadata. For backward compatibility
with K1, delegated methods to Java types are deserialized as stable.
^KT-40480 Fixed
The original synthetic properties from Java were not cached anywhere and
created anew for every session. However, the enhanced properties are
(along with their originals) saved inside the session's cache, causing
inconsistency with newly created symbols via referential equality.
K1 allows writing access to a public setter of a protected synthetic
property only if the call is inside a subclass. K2 previously allowed
that unconditionally. This changes brings the behavior in line with K1.
^KT-56050 Fixed
Dmitrii Gridin