In the original fix for KT-39809, the Kapt plugin was not given a proper
empty implementation stub: it was added to `Kapt3GradleSubplugin`, while
originally the Kapt subplugin's META-INF/services entry pointed to
`Kapt3KotlinGradleSubplugin`.
This commit makes the correct class implement the legacy interface.
Issue #KT-39809 Fixed
In the `KotlinPlatformType` disambiguation rule, don't prefer `common`
when there's a `jvm` or an `androidJvm` variant, as this would conflict
with disambiguation rules created by the other plugins, such as Gradle's
`java` which will choose `org.gradle.usage=java-api` and lead to
ambiguity.
Issue #KT-32239 Fixed
There's no known problems connected with this change, but wrong
comparison might cause tests flakiness.
`allowKotlinPackage` and `classpath` fields were not included.
Right now this is only supposed to be turned on locally (`./gradlew
-Pkotlin.build.useIR=true ...`), to be able to quickly try how JVM
IR-compiled Kotlin compiler works.
This test causes a build timeouts on CI which cannot be reproduced
locally. So we disable them to not block the testing process until
a proper fix is found.
Its support complicates JS StringBuilder implementation with no actual
performance improvements. Benefits of having capacity() function
in common code are also not completely clear.
Relates to KT-33069
#KT-40168
Content was changed, so we should force reindex.
Minor changes:
- There is no need to save a string, we can just save nothing
by using the Unit value (see UnitKey.save and UnitKey.read)
- Unit can be shared between all indexes, so we can extract UnitKey object
- It would be good to extract abstract class FileListIndex:
- for better readability: separate the logic of the specific index from the common FileListIndex implementation
- someone can use it also
- mapOf (Unit to null) will create singletonMap itself and more readable
- ScriptTemplatesClassRootsIndex.KEY perhaps better to call NAME
- prevent analyzing .gradle.kts files until all services are loaded
- remove services caches where it is not required
- replace cached services with cache only during vfs events batch processing
- prevent services loading in actions updating
It was mutable anyway in many subclasses. This is needed in order to
avoid depending on concrete IR implementations in the JVM IR backend
where it's necessary to be able to change visibility.
To avoid casting to specific Ir*Impl elements at call sites.
Also inherit from IrMetadataSourceOwner only where it's needed: class,
file, function, property. Previously this field was always null and took
some space for things like value parameters, type parameters, etc.
Sergey Igushkin