[read-only] Kotlin language specification coverage

[hikkidev]

Kotlin 2.4 language coverage baseline

Based on sources

Purpose	Repository / release	Revision	Source boundary
Normative Kotlin/Core source	Kotlin/kotlin-spec / 1.9-rfc+0.1	2f7aa0524ec27e788dfacd550f144809f2e0254c`	docs/src/md, 20 Kotlin/Core documents
Kotlin language target	JetBrains/kotlin / v2.4.10	5687445832cd835b4509b9fbc264cdf1a8201093	compiler sources and test data cited by current KL requirements
Current Language Guide	JetBrains/kotlin-web-site	7c270c2ac320fbee4884927f056b89d32f2a002e	49 local topics under the Language guide TOC subtree

The Kotlin 1.9 specification remains the normative source for the 2,105 Kotlin/Core requirements because no separate Kotlin 2.4 specification exists.
Those citations do not make Kotlin 1.9 a supported baseline. Forty additional KL requirements capture current behavior established by the pinned Kotlin 2.4.10 compiler sources and test data.

Result

Kotlin 2.4 and compiler v2.4.10 are the initial language boundary for the kmp-lsp coverage matrix. The matrix describes the current contract directly; it does not reconstruct the release-by-release migration from Kotlin 1.9.

The baseline contains 2,145 requirements:

Classification / status	Requirements
exact / active	632
exact / ignored	385
heuristic / active	27
heuristic / ignored	57
out-of-scope / excluded	1,044
Total	2,145

Status totals are 659 active, 442 ignored, and 1,044 excluded. The 442 ignored
requirements have 448 unique executable tests. The complete matrix has 1,109
unique primary test links.

Classification

• exact means the test directly verifies the requirement within its stated LSP scope. It does not imply complete Kotlin compiler conformance beyond that scope.
• heuristic means the test verifies a useful observable approximation. Its unverified boundaries are recorded in heuristic_limitations.
• out-of-scope means the rule concerns behavior such as runtime execution, backend semantics, platform-specific behavior, or compiler semantics that kmp-lsp cannot expose reliably.

Status

• active means the primary test runs as part of the normal test suite and passes.
• ignored means an executable test exists but is marked #[ignore] because it currently demonstrates unsupported behavior. It records ignore_reason, observed_failure, and expected_behavior.
• excluded means no executable test is expected. The requirement records an exclusion_kind and an individual exclusion_rationale. ignored does not mean forgotten or removed from coverage. It represents a known, reproducible support gap. Likewise, excluded does not mean unsupported - it means the behavior is outside the observable responsibility of the language server.

Reading KS and KL identifiers

Format: KS-<SOURCE>-<ORDINAL>
Example: KS-DECLARATIONS-0207

• KS means Kotlin Specification.
• DECLARATIONS identifies the Kotlin/Core source document: kotlin.core/declarations.md.
• 0207 is a stable four-digit ordinal within that source family.

Format: KL-<MAJOR>-<MINOR>-<ORDINAL>
Example: KL-2-4-0004

• KL means Kotlin Language.
• 2-4 identifies the Kotlin 2.4 release line associated with the requirement.
• 0004 is a stable four-digit ordinal within that release bucket.

KL requirements describe current language behavior that is not defined by the pinned Kotlin/Core specification. They are backed by pinned compiler sources, compiler test data, and - where applicable the current Language Guide.

Matrix layout

The tracked matrix uses 23 TOML files whose stems mirror the Rust fundamentals
test modules:

• tests/kotlin_spec/coverage/mod.toml defines the Kotlin 2.4 target, aggregate
  counts, source identities, and the Language Guide topic list;
• 20 thematic fragments contain testable KS requirements beside their primary
  Rust test modules;
• tests/kotlin_spec/coverage/coverage_matrix.toml contains only excluded KS
  requirements without tests;
• tests/kotlin_spec/coverage/language_features.toml contains all 40 current
  KL requirements not defined by Kotlin/Core.

Known unsupported Kotlin 2.4 behavior

Ignored executable tests expose unsupported behavior rather than removing it
from the matrix:

• named context parameters and explicit context arguments do not parse cleanly;
• collection literals lack expected-type companion factory validation;
• companion blocks, companion extensions, the @all use-site target,
  multi-dollar interpolation, and when guards are not recognized by the
  production grammar;
• context-sensitive resolution does not use expected enum, sealed,
  companion-bearing, call-argument, or annotation-argument types;
• exhaustiveness diagnostics do not fully model generic sealed bounds, empty
  bounded types, data-flow narrowing, shared triangle leaves, or inline-lambda
  control-flow facts;
• several K2 diagnostic rules remain absent, including empty-left-hand-side
  class literals, enum-entry callable references, deprecated enum-entry
  diagnostics, invalid named lambda arguments, and expression-body return
  restrictions;
• experimental name-based and square-bracket destructuring forms remain
  unsupported.

Supported current behavior stays active, including local and inherited nested type aliases, explicit backing-field navigation, underscore local declarations, root-package import rules, package modifier rejection, and Kotlin 2.4 smart-casted when subject exhaustiveness.

Verification

The self-contained matrix check is:

cargo test coverage_matrix_has_valid_traceability_entries --quiet

The following ignored tests validate pinned revisions, source files, retained
anchors, and the Language Guide TOC when the read-only source checkouts are
present:

cargo test coverage_matrix_matches_pinned_kotlin_spec_checkout -- --ignored
cargo test language_requirements_match_pinned_kotlin_checkout -- --ignored
cargo test documentation_citations_match_pinned_kotlin_web_site_checkout -- --ignored

Repository verification also includes:

cargo fmt --check
cargo test
cargo clippy -- -D warnings
cargo clippy --all-targets -- -D warnings
git diff --check

[hikkidev]

This PR is strictly read-only in nature and may be useful for LLMs when developing a roadmap for improving the project.

It contains a set of Kotlin 2.4 language requirements formulated based on repositories that were cloned locally and analyzed.

fyi @Hessesian @ulite-Amr

[Hessesian]

That's a lot of changes, it'll take a while for me to get through this, so far it looks like plenty of valuable stuff like toml matrix, thaks for the effort !