This method can be useful when overriding a throwing Kotlin method in
Swift or Obj-C. In this case, a user can call asError to wrap Kotlin exception
to (NS)Error and then throw it to Kotlin, which will unwrap it back.
^KT-45127 Fixed
This is needed to reuse EffectiveVisibility in FIR, because typeContext
in it is used to call `isSubtypeOf`, and in FIR it's required to use
context from use site session (to see all declaration which are
available in module)
KotlinTypeMapper.mapInlineClassTypeAsDeclaration and
mapUnderlyingTypeOfInlineClassType invoked mapType which is defined in
descriptorBasedTypeSignatureMapping.kt and works on KotlinType.
It didn't lead to any problems, other than the fact that we were
constructing IrBasedClassDescriptor in JVM IR, and then KotlinType to
pass it to mapType, on each call to StackValue.boxInlineClass or
unboxInlineClass, which seems wasteful.
Instead of this, refactor these utilities to use type markers instead,
pass IrType and IrTypeMapper directly from JVM IR, and move the "static
type mapper" logic (which is used only in the old backend) out of
KotlinTypeMapper.
Before this fix, if some imports were not resolved during compilation,
this result had been saved in caches, and this import couldn't been
resolved during following compilations even if it was added to the
module dependencies. This commit adds special handling of resolution
caches for the REPL compiler.
Compiler check for 'when' exhaustiveness requires that module
descriptors of a sealed class and its inheritors are the same (reference
identity matters). Prior to this commit and under some conditions they
were not. Details follow below.
Resolution related data structures (resolution facades) are organized
into trees (sdks, libs, and modules have their own nodes/facades,
module/class descriptors are stored inside). And the trees themselves
are put into a map associating so called PlatformAnalysisSettings and
GlobalFacades (plays a role of a root). PlatformAnalysisSettings is an
abstraction describing target platform and sdk of a module. The more
combinations exist for a project the more facades are used. Please, see
KotlinCacheService for more details.
So why a module can have multiple ModuleDescriptor-s?
Every tree mentioned above is an isolated resolution environment
containing its own instances of the outer world descriptors. Say, if a
project has modules X, Y, Z and we consider X then all three might have
their own vision of X, i.e. 3 descriptors exist at a time.
What descriptor instance does compiler get?
The path starts when the user opens a file in the editor and
highlighting pass starts (see usages of
ResolutionUtils#analyzeWithAllCompilerChecks). Module descriptor stored
in the resolution tree of the file's module gets injected into the
compiler's context. Starting from this moment compiler sees other
modules through the prism of a single resolution facade (tree).
Descriptors residing outside are alien.
This commit allows IdeSealedClassInheritorsProvider to figure out what
PlatformAnalysisSettings are associated with the resolution facade (read
ModuleDescriptor) seen by the compiler. Later on the same facade is used
to provide correct instances of sealed inheritors back to the compiler.
Use the same logic as for type constructors of classes, based on the
fully-qualified name of the classifier, with special cases for error
types and local declarations, with an additional check that the type
constructors' declaration descriptors are structurally equal via
`DescriptorEquivalenceForOverrides`. The latter is required because type
parameters of overloaded functions must be different, even though their
full FQ name is the same.
This (hopefully) has no effect for the compiler, but is useful for
kotlin-reflect where `KType.equals` runs the type checker on the
underlying `KotlinType` instances, which eventually ends up comparing
type constructors. Descriptors and types in kotlin-reflect are cached on
soft references, so they may be suddenly garbage-collected and
recomputed, and we want copies of the same type parameter to be equal to
each other.
This fixes flaky codegen tests which started to fail after migration to
the new test infrastructure, where tests are now run in parallel in the
same process, thus with higher memory pressure and more soft references
being GC'd:
* `codegen/box/reflection/types/createType/typeParameter.kt`
* `codegen/box/reflection/supertypes/genericSubstitution.kt`
Also, add a new test to check that we do the instanceof check in
overrides of `AbstractTypeConstructor.isSameClassifier`.
#KT-44850 Fixed
This commit introduces partial support of descriptorKindFilter in
`AbstractPsiBasedDeclarationProvider`. Without it there may be an error
in following case:
```
sealed class Base
class Derived : Base()
class Test<out V>(val x: Base) {
private val y = when (x) {
is Derived -> null
}
}
```
Here we start to resolve type of `y`, then go to computation of inheritors
of sealed class Base, which also may be inside Test, so we need get all
nested classifiers in Test. But without this filtration we will start
computing descriptor for `y` again, which leads to ReenteringLazyComputationException
#KT-44316 Fixed
findDecompiledDeclaration.kt: Use same DescriptorRenderer options as Decompiler
DescriptorRendererImpl.kt: not enforce different AnnotationArgumentsRenderingPolicy for function type annotations
This will fix KTIJ-563 where rendered Descriptors are used as Keys
for GOTO navigation into decompiled sources.
^KTIJ-563 fixed
Fix built-ins for JVM platform and make them consistent
with module's dependency on standard library. Changes
don't affect non-JVM platforms.
Previously all built-ins in IDE were loaded from classloader
and were based on the same pre-serialized .kotlin_builtins files.
This approach is generally not correct as built-in declarations
differ for different platforms, but it had been working for a while
without immediately observalble effects (see KT-33233 for more info).
After changes in standard library JvmBuiltins started producing
false errors (see KT-39728).
To fix this, JVM built-ins in IDE now utilize the same technique as
applied in CLI: using dependency on standard library as a module
for built-ins instead of artificial module that considers only
.kotlin_builtins.
Change summary:
- Provide JvmBuiltins with kind FROM_DEPENDENCIES
for all modules with stdlib dependency in IDE
- Add JvmBuiltinsPackageFragmentProvider to JVM-ish module resolvers
(JVM and Composite with JVM platform) to support their use as
built-ins module
- Create KotlinBuiltInsMetadataIndex file index for tracking libraries
containing .kotlin_builtins to support JvmBuiltinsPackageFragmentProvider
- Create KotlinStdlibIndex file index for tracking kotlin-stdlib(-common),
which looks for "Kotlin-Runtime-Component" manifest attribute
- Add caching service to track LibraryInfo for kotlin-stdlib(-common)
- Put LibraryInfo for kotlin-stdlib(-common) alongside SDKs
due to the need to resolve that modules in BuiltInsCache
- Update BuiltInsCache to separate JvmBuiltins by module's dependency
on stdlib and JDK
- Make platform of KotlinSDK common instead of JVM
- Set built-ins module lazily in IDE
^KT-33233 Verification Pending
Use {de,}capitalizeAsciiOnly and to{Lower,Upper}CaseAsciiOnly where
possible, and stdlib's functions with Locale.US everywhere else.
Otherwise, if the default system locale is Turkish, the capital latin
letter "I" is transformed in toLowerCase to "ı" (see
https://github.com/JetBrains/kotlin/blob/66bc142f92085047a1ca64f9a291f0496e33dd98/libraries/stdlib/jvm/test/text/StringJVMTest.kt#L119),
which for example breaks the codegen for `intArrayOf` in
KT-25400/KT-43405.
Similarly, lower case latin letter "i" is transformed to "İ".
#KT-13631 Fixed
#KT-25400 Fixed
#KT-43405 Fixed
Victor Petukhov