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
This commit adds relevant functions: hashCode, toString, equals
(if the class is not a data class)
And supertype j.l.Record
It only affects descriptor contents, i.e. works for FE
^KT-43677 In Progress
including varargs, apparently.
So, we allow unsigned types and unsigned arrays in annotations,
but disallow user-defined inline classes.
#KT-23816 Fixed
Smartcasts for public properties from different module are not
stable because module declaring a property in general can be
compiled separately from the module using it. However, if client
module has dependsOn relation with declaring module their simultaneous
compilation is guaranteed which makes this smart cast safe.
Cache all transitive 'expected by' modules in module dependencies.
Extend test to check smart casts are allowed for properties from transitive
'expected by' dependencies and prohibited otherwise.
^KT-42754 Fixed
In the compiler, this function was used in psi2ir (and it affected
nullability annotations in the resulting JVM class files), in "useless
elvis with null on the right side" diagnostic checker, and in light
classes.
#KT-42650 Fixed
Motivation:
- drop getArguments from type context as a duplicate of getArgumentList
- reduce the number of collection allocations in getAllDeeplyRelatedTypeVariables
Additional minor improvements, test data fixes
Repeat the logic of KotlinConstraintSystemCompleter in ConstraintSystemCompleter.
Implement additional context operations required for updated lambda completion algorithm.
Mads Ager