Kotlin Compiler and Analysis API

The compiler/ir/serialization.common module handles the (de)serialization of Intermediate Representation (IR) into the Protobuf 2 format, including its linkage and validations. This process is essential for storing compiled library code that can be linked into final applications.

Usage Scenarios

• JVM Backend: In the experimental -Xserialize-ir mode, IR is stored within special annotations inside .class files. This allows one module to copy the IR of inline functions compiled into another module. In the default mode (without IR storage), inlining is performed by copying JVM bytecode instead.
• Other Backends: Libraries are compiled into .klib files, which contain both the IR and necessary metadata.

The swift-export-standalone-integration-tests directory provides infrastructure and test cases for the swift-export-standalone module. The testing suite is categorized by test type and test group:

Test Kinds:

• generation: Compares swift-export-standalone artifacts against established 'golden data'.
• execution: Runs Swift tests against the generated API.

Test Groups:

• simple: Synthetic tests designed to verify specific features of Swift export.
• external: Tests the behavior of Swift export against real-world libraries.

The libraries directory contains the source code for several core Kotlin libraries. These libraries are built as part of the root Gradle project.

Included libraries:

• kotlin-stdlib: The standard library for Kotlin/JVM and Kotlin/JS, including additional parts for JDK 7 and JDK 8.
• kotlin-reflect: Provides full reflection support.
• kotlin-test: A multiplatform library for unit testing.
• kotlin-annotations-jvm: Annotations designed to improve type visibility and usability when Java code is consumed by Kotlin code.

The kotlin-stdlib-docs project is responsible for generating the API documentation builds used on the official kotlinlang.org website. It specifically covers the documentation for the following libraries:

• kotlin-stdlib
• kotlin-reflect
• kotlin-test

The dtoa module provides functionality for converting between floating-point numbers and strings. This implementation is adapted from Apache Harmony and is split between C++ and Kotlin.

This specific directory contains the C++ implementation. If you need to work with the Kotlin-side logic, you must look in the Kotlin runtime source instead.

The kotlinx-metadata library is a platform-agnostic component designed to read and modify Kotlin declaration metadata within binary files (such as .class and .js files) emitted by the Kotlin compiler.

Note: This specific module is not released as a standalone library. If you are working specifically with JVM binaries (.class and .kotlin_module files), you should use kotlinx-metadata-jvm instead.

The Swift export modules are responsible for translating Kotlin declarations into Swift and constructing the necessary function bridges between the two languages. This allows Kotlin code to be consumed within a Swift environment.

For a high-level architectural overview and detailed guidance, refer to the official documentation at ../../docs/swift-export/README.md within the repository.

The K2 implementation of the Kotlin compiler frontend is built around the FIR (Frontend Intermediate Representation). It is responsible for the core stages of the compilation process before code generation, specifically:

• Desugaring: Transforming high-level language constructs into simpler FIR forms.
• Resolution: Determining which symbols (functions, properties, etc.) are being referred to.
• Type Inference: Calculating the types of expressions based on context and declarations.
• Diagnostics: Generating errors, warnings, and other compiler messages.

For a deep dive into the underlying architecture, refer to the FIR Basics design documentation.

The org.jetbrains.kotlin.ir.backend.js.ic package provides the logic for incremental code generation in the Kotlin/JS IR backend. It transforms existing klib IR into final JavaScript code without re-compiling the entire project.

The incremental process follows these steps:

1. Receives an already-built klib.
2. Detects 'dirty' files (files with modified IR).
3. Identifies additional files that require re-lowering (e.g., callers of a modified inline function).
4. Runs the lowering pipeline for both the direct dirty files and the identified additional dirty files.
5. Incrementally generates the final JavaScript code based on the klib IR.

Note: This package does not handle incremental klib compilation (the process of compiling .kt files to .klib); that is a separate process handled elsewhere.