Set of compiled source sets is already available in
MultiplatformModelImportingContext via
'sourceSetsToParticipatedCompilations.keys', no need to recompute it
^KT-37127
Build dependsOn closure straight away by using KotlinSourceSetProto
instead of building first KotlinSourceSetImpls with incorrect
dependsOn-names, and then discarding it
^KT-37127
Essentially it is responsible for returning various information about
the model being imported, such as:
- flags and properties, which configure the process of import
- "bulk" requests which might be needed multiple times during import,
but which are more convenient to be computed once, like various indices
(source sets by name, compilations by source-sets, etc.)
^KT-37127
Looks like it has been broken by 40633768bc
where 'KotlinCompilation.dependencies' switched its type from
KotlinDependency (which is alias to
org.jetbrains.plugins.gradle.model.ExternalDependency) to
KotlinDependencyId (which is alias to Long), leading to safe-cast in the
'reportUnresolvedDependencies' to be always evaluated to 'null'
Rationale for removing it completely instead of fixing:
No one has noticed that this function has been broken + I haven't
managed to find any user-visible behaviour it adds (tried fixing it and
checking project similar to one from
NewMultiplatformProjectImportingTest.testUnresolved, no difference for
me).
Note that in previous line we already check for !isHmppEnabled and for
sourceSet.name == KotlinSourceSet.COMMON_TEST_SOURCE_SET_NAME, and if it
holds, then we continue to the next loop iteration. So, this conditional
here is essentually equal to 'false'
For most of those the behaviour isn't set in stone, though at the moment
of making that commit we're more or less sure that it's reasonable.
Behaviour in some cases might be more strictly enforces (as much as you
can enforce something in esoteric cases with misconfigured project
sturcture). Those are marked with comments with '!'.
Note the behaviour in 'precisePlatformsWithUnrelatedModuleHmpp': it is
incorrect, as set of platforms still contains unrelated platforms.
This is because in the current solution, some source-sets
(commonMain/commonTest) always receive COMMON platform and then it gets
coerced to set of targets actually seen in the project.This helps if
projects uses as much targets as current module (like in
precisePlatformsHmpp), but fails if it uses more targets than the
current module (like in precisePlatformsWithUnrelatedModuleHmppp)
The upcoming commits will fix that issue
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
It doesn't matter because this built-ins instance will be used only to
get names of default imports, so nothing can be resolved to those
built-ins => no diagnostics will be reported
Ilya Kirillov