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
- KtClassLikeSymbol.primaryConstructor was removed
- Constructors were removed from getCallableMembers because
constructors has no name (or special name `<init>`) and previous
implementation was incorrect
- KtScope.getAllSymbols returns constructors as before. Before it was
like this because of the incorrect implementation of getCallableMembers
- getConstructors has sence only for class scope,
for the rest cases it is empty
This visibility is used for some cases where it isn't allowed to access
to private members of the object from other instances of the same object
because of the type parameter variance.
For almost all clients this visibility is the same as PRIVATE
So far, quick-fix tests infrastructure neither supports the check
for multiple files (several .before/.after pairs) nor multi module
structure. Provided tests are quite limited yet allow to make sure that
the fix in question appears in expected context and get activated.
^KT-44043 fixed
Exclude modules where there are still warnings in an explicitly declared
variable `tasksWithWarnings`.
Also remove "-progressive" from compiler arguments in modules which are
built with non-latest language version, as the warning about that leads
to an error with -Werror.
Dmitriy Novozhilov