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
Ilya Kirillov