Adds implementation and tests for the new
KtClassOrObjectSymbol.annotationApplicableTargets property on
KtSymbolInfoProvider. This implementation delegates to the canonical
implementation in AnnotationChecker for FE1.0, and to the implementation
in FirAnnotationHelpers for FIR.
This change also includes direct tests for annotationApplicableTargets,
and a fix for FirClassLikeSymbol.getAllowedAnnotationTargets in
FirAnnotationHelpers.
After this commit we:
- preserve Enum.entries synthetic property in tower even in case the bound feature is OFF
- report an error on Enum.entries call in specific checker if the feature is OFF
- give this synthetic property lower priority, no matter feature ON or OFF
#KT-55251 Fixed
- Make the implementations very similar, to fix KT-54833 where the
companion object case was forgotten for kotlinProperty.
- Optimize both functions to look up the function/property by name
first, to cover the most probable case when the JVM name of a
declaration is equal to its Kotlin name. This fixes KT-55937.
#KT-54833 Fixed
#KT-55937 Fixed
Otherwise, when adding a typealias to core/builtins, it leads to an
exception "JvmBuiltins instance has not been initialized properly". It
happens because we start computing typealias constructors even before
the compiler has been initialized properly.
Basically we're creating the container, and as a part of it, we're
computing default imports, and for that we need to get all top-level
classifiers from scopes imported by default, which includes typealiases.
Eager call to `getTypeAliasConstructors` here results in computing
constructors of the class descriptor on the RHS of the type alias, which
is not possible if that class is built-in, since the container has not
yet been created and thus `JvmBuiltIns` has not been initialized yet.
No tests added, and no issue is affected because, as mentioned above,
the problem is only reproducible if we add something to core/builtins.
Review: https://jetbrains.team/p/kt/reviews/8360
MetadataComparisonTest was the only one in build-tools module who
depended on util-klib, that's why we can drop build-tools -> util-klib
dependency
MetadataComparisonTest is no longer needed, that's why we can drop it.
The dependency drop is a one step forward in dropping
`kotlin.srcDir("../compiler/util-klib/src")` line in
`buildSrc/build.gradle.kts`. Adding source roots in `buildSrc` is hacky
and can lead to frustrations (e.g. KT-55874). That's why it's desirable
to drop buildSrc -> util-klib hacky dependency.
Unfortunatelly, I couldn't drop buildSrc -> util-klib dependency,
because:
1. buildSrc depends on kotlin-native/shared/src/library/kotlin +
buildSrc depends on kotlin-native/tools/kotlin-native-gradle-plugin +
maybe smth else
2. kotlin-native/shared/src/library/kotlin depends on util-klib +
kotlin-native/tools/kotlin-native-gradle-plugin depends on util-klib +
maybe smth else
A LookupSymbol should only refer to either a class, a class member, or a
package member.
When a LookupSymbol refers to a file facade (e.g.,
LookupSymbol(name="FooKt", scope="com.example")), it is redundant as it
doesn't impact the IC analysis to find files to recompile.
Previously, the new IC (ClasspathChangesComputer) would fail when
detecting that IncrementalJvmCache reported these redundant
LookupSymbols. With this change, the new IC will just ignore them.
Note: A better approach would be to fix IncrementalJvmCache to not
report these LookupSymbols, but it will require some significant
cleanup/refactoring work, so we can consider it later.
Test: New KotlinOnlyClasspathChangesComputerTest.testRenameFileFacade
^KT-55021 Fixed
The method must return an empty set in that case, instead of null
that would mean we can't compute it.
The problem was found when running FirLoadCompiledKotlinGenerated
The main idea is pre-computing the sets of names that might be
met there, that helps to decrease the sizes of the backing maps
(by avoiding irrelevant keys)
Totally, this branch with previous commits speeds up MT Full Kotlin
approximately on 3 seconds (~5%)
Avoid filling caches with keys that are definitely empty
(if it's cheap to compute that), to decrease the size of backing maps.
The strategy is pre-computing the sets of names that might be met.
NB: the size of the sets is way fewer than a size of all queried names.
in startCoroutineUninterceptedOrReturn. Otherwise, the coroutine will
not be interceptable later.
Add a test, which checks, that intercepted continuation is released.
#KT-55869
Stanislav Ruban