Marco Pennekamp
6474ff88fa
- Previously, only callable package name sets were implemented, because the compiler cannot economically compute classifier package sets for libraries. This has not changed. However, the K2 IntelliJ plugin and standalone Analysis API can very easily compute classifier package sets. Hence, this commit adds support to `FirSymbolNamesProvider` for such sets. - Similar to callable package sets, classifier package sets (1) improve the memory usage of symbol names providers and (2) improve the performance of `mayHaveTopLevelClassifier`, which is a significant bottleneck in the IDE. - In many cases, the package sets for callables and classifiers are the same. For example, the IDE Kotlin declaration provider computes the set of packages that contain any classifier and/or callable, for the following reasons: (1) indexing package names without filtering for declarations is much faster, (2) computing separate sets is not free both in time and memory, and (3) the performance impact of having a more narrow set for callables is expected to be negligible. For this reason, `FirSymbolNamesProvider.getPackageNames` exists to provide a shared package set. - The `hasSpecific*PackageNamesComputation` properties are required to avoid caching the same package set in cached symbol names providers twice. Because these properties are constant, they can be checked very quickly, and no time has to be wasted trying a specific package set computation to find out whether it's supported. ### IDE Performance Results Package set construction performance improved in the IDE in multiple benchmarks. This improves the performance of symbol providers overall, which has a direct impact on completion, code analysis, and Find Usages. In a local manual run of the `intellij_commit/setUp` Find Usages performance test, the total time spent in `getClassLikeSymbolByClassId` improved from ~18.7s to ~11.2s. Due to parallel resolve, this does not translate to a wall clock improvement of 7 seconds, but rather of a few seconds. Some performance tests improved markedly in warmup, with for example `toolbox_enterprise/genUuid` Find Usages having an improvement in `StubBasedFirDeserializedSymbolProvider.getClassLikeSymbolByClassId` from 2.4s to 0.2s. This has a direct impact on the first-run performance of the tested Find Usages command. So far, classifier package sets in the IDE are only implemented for libraries, and library sessions are cached after the first warmup. Because the biggest impact of classifier package sets is avoiding computation of "class names in package" sets, the impact of this optimization is not accurately reflected in the timings reported by our performance tests. `toolbox_enterprise/genUuid` above is a good example, as the warmup timings are great, but after warmup, `StubBasedFirDeserializedSymbolProvider.getClassLikeSymbolByClassId` improved only from 150ms to 70ms. `toolbox_enterprise/genUuid` is another example, as we can confidently say that the first-run Find Usages performance has improved (which makes a difference for the user), but it is unclear by how much, as warmup is not measured in performance tests. The same optimization for source sessions will be easier to measure, as source sessions are invalidated after each performance test run. This commit lays the groundwork for that as well, because source session support only requires the requisite package set computation in the IDE declaration provider to be implemented. ^KT-62553 fixed
Kotlin Programming Language
Welcome to Kotlin!
It is an open-source, statically typed programming language supported and developed by JetBrains and open-source contributors.
Some handy links:
- Kotlin Site
- Getting Started Guide
- Try Kotlin
- Kotlin Standard Library
- Issue Tracker
- Kotlin YouTube Channel
- Forum
- Kotlin Blog
- Subscribe to Kotlin YouTube channel
- Follow Kotlin on Twitter
- Public Slack channel
- TeamCity CI build
Kotlin Multiplatform capabilities
Support for multiplatform programming is one of Kotlin’s key benefits. It reduces time spent writing and maintaining the same code for different platforms while retaining the flexibility and benefits of native programming.
- Kotlin Multiplatform Mobile for sharing code between Android and iOS
- Getting Started with Kotlin Multiplatform Mobile Guide
- Kotlin Multiplatform Benefits
- Share code on all platforms
- Share code on similar platforms
Editing Kotlin
Build environment requirements
This repository is using Gradle toolchains feature to select and auto-provision required JDKs from AdoptOpenJdk project.
Unfortunately AdoptOpenJdk project does not provide required JDK 1.6 and 1.7 images,
so you could either download them manually and provide path to installation via JDK_1_6 and JDK_1_7 environment variables or
use following SDK managers:
Alternatively, it is still possible to only provide required JDKs via environment variables
(see gradle.properties for supported variable names). To ensure Gradle uses only JDKs
from environmental variables - disable Gradle toolchain auto-detection by passing -Porg.gradle.java.installations.auto-detect=false option
(or put it into $GRADLE_USER_HOME/gradle.properties).
For local development, if you're not working on the standard library, it's OK to avoid installing JDK 1.6 and JDK 1.7.
Add kotlin.build.isObsoleteJdkOverrideEnabled=true to the local.properties file, so build will only use JDK 1.8+. Note, that in this
case, build will have Gradle remote build cache misses for some tasks.
Note: The JDK 6 for MacOS is not available on Oracle's site. You can install it by
$ brew tap homebrew/cask-versions
$ brew install --cask java6
On Windows you might need to add long paths setting to the repo:
git config core.longpaths true
Building
The project is built with Gradle. Run Gradle to build the project and to run the tests using the following command on Unix/macOS:
./gradlew <tasks-and-options>
or the following command on Windows:
gradlew <tasks-and-options>
On the first project configuration gradle will download and setup the dependencies on
intellij-coreis a part of command line compiler and contains only necessary APIs.idea-fullis a full blown IntelliJ IDEA Community Edition to be used in the plugin module.
These dependencies are quite large, so depending on the quality of your internet connection you might face timeouts getting them. In this case, you can increase timeout by specifying the following command line parameters on the first run:
./gradlew -Dhttp.socketTimeout=60000 -Dhttp.connectionTimeout=60000
Important gradle tasks
clean- clean build resultsdist- assembles the compiler distribution intodist/kotlinc/folderinstall- build and install all public artifacts into local maven repositorycoreLibsTest- build and run stdlib, reflect and kotlin-test testsgradlePluginTest- build and run gradle plugin testscompilerTest- build and run all compiler tests
To reproduce TeamCity build use -Pteamcity=true flag. Local builds don't run proguard and have jar compression disabled by default.
OPTIONAL: Some artifacts, mainly Maven plugin ones, are built separately with Maven. Refer to libraries/ReadMe.md for details.
To build Kotlin/Native, see kotlin-native/README.md.
Working with the project in IntelliJ IDEA
It is recommended to use the latest released version of Intellij IDEA (Community or Ultimate Edition). You can download IntelliJ IDEA here.
After cloning the project, import the project in IntelliJ by choosing the project directory in the Open project dialog.
For handy work with compiler tests it's recommended to use Kotlin Compiler Test Helper
Dependency verification
We have a dependencies verification feature enabled in the
repository for all Gradle builds. Gradle will check hashes (md5 and sha256) of used dependencies and will fail builds with
Dependency verification failed errors when local artifacts are absent or have different hashes listed in the
verification-metadata.xml file.
It's expected that verification-metadata.xml should only be updated with the commits that modify the build. There are some tips how
to perform such updates:
- Delete
componentssection ofverification-metadata.xmlto avoid stockpiling of old unused dependencies. You may use the following command:
#macOS
sed -i '' -e '/<components>/,/<\/components>/d' gradle/verification-metadata.xml
#Linux & Git for Windows
sed -i -e '/<components>/,/<\/components>/d' gradle/verification-metadata.xml
- Re-generate dependencies with Gradle's
--write-verification-metadatacommand (verify update relates to your changes)
./gradlew -i --write-verification-metadata sha256,md5 -Pkotlin.native.enabled=true resolveDependencies
resolveDependencies task resolves dependencies for all platforms including dependencies downloaded by plugins
- If you’re adding a dependency with OS mentioning in an artifact name (
darwin,mac,osx,linux,windows), remember to add them toimplicitDependenciesconfiguration or updateresolveDependenciestask if needed.resolveDependenciesshould resolve all dependencies including dependencies for different platforms.
Using -dev and -SNAPSHOT versions
We publish -dev and -SNAPSHOT versions frequently.
For -dev versions you can use the list of available versions and include this maven repository:
maven("https://maven.pkg.jetbrains.space/kotlin/p/kotlin/bootstrap")
For -SNAPSHOT versions that are updated daily, you can use the list of available versions and include this maven repository:
maven("https://oss.sonatype.org/content/repositories/snapshots/")
License
Kotlin is distributed under the terms of the Apache License (Version 2.0). See license folder for details.
Contributing
Please be sure to review Kotlin's contributing guidelines to learn how to help the project.