[Roadmap] Enhancing KMP Tooling, Semantic Diagnostics, and Smart Type Systems

[ulite-Amr]

Context & Goals

The current Indexer architecture in kotlin-lsp-rs is incredibly fast, memory-safe, and highly concurrent. However, to elevate this LSP into a robust IDE-grade developer experience, we need to bridge the gap between fast autocomplete and true Semantic Analysis & Static Type Safety.

I am planning to implement a comprehensive suite of features over the next few days to introduce full diagnostic reporting (red squiggly lines), advanced cross-platform KMP navigation, and smart casting.

Below is the detailed architectural roadmap of what I am currently working on.

---

🗺️ Engineering Roadmap & Feature Specs

1. Cross-Platform KMP Navigation (expect / actual CodeLens) ✅ COMPLETED

• The Problem: Navigating Kotlin Multiplatform (KMP) codebases between commonMain definitions and native target implementations (androidMain, iosMain) is friction-heavy.
• The Solution: Implement an LSP textDocument/codeLens provider.
• Rust Implementation: Our Indexer already parses fully-qualified names globally. We will traverse the file's AST looking for symbols marked with expect or actual. The CodeLens provider will query the qualified map in the Indexer to resolve cross-module links and overlay virtual clickable text (└── ◆ iOS Actual | ▣ Android Actual). Clicking it invokes textDocument/definition via a resolved Location link.
• Extras:
  • Neovim/Helix support via window/showDocument fallback in execute_command
  • Dynamic modifier verification — live-tree parse confirms counterpart carries the expected modifier
  • Missing-actual diagnostics — warns when a platform source set lacks an actual implementation for a declared expect
  • One-click code action — creates missing actual files with TODO body and post-creation navigation
  • Platform groups simplified to match real KMP default hierarchy (10 groups: common, android, apple, ios, jvm, js, native, macos, linux, wasm)

2. Dead Code Elimination (Unused Symbols Diagnostic)

• The Problem: Dead code and stale imports reduce project maintainability and performance.
• The Solution: Emit DiagnosticSeverity::HINT on unused variables, functions, and imports so editors can grey them out, coupled with a CodeAction to remove them.
• Rust Implementation:
  During the AST traversal pass of a single file, we will collect all internal declarations into a HashSet. As the file walker parses the expression blocks, any identifier hit will be removed from the HashSet. At the end of the document pass, the remaining elements in the set represent dead code, triggering a hint diagnostic.

3. Smart Casts & Scope-Aware Type Overrides

• The Problem: Kotlin relies heavily on smart casts (e.g., if (obj is String) { ... }). Outside that block, using it as a subclass should throw a type error, while inside, its type must be dynamically upgraded.
• The Solution: Introduce a lightweight scope-tracking mechanism or a micro-Control Flow Graph (CFG) inside our diagnostic pass.
• Rust Implementation:
  When evaluating an if_expression containing an is_expression condition, the local semantic resolver will inject a temporary type override inside that specific block scope. Upon reaching the end node (}) of the block, the type variable falls back to its original supertype (Any). Accessing subclass methods outside the scope will trigger an unresolved method diagnostic.

4. Unresolved Supertypes & Inheritance Restrictions

• The Problem: In Kotlin, classes are final by default. Inheriting from a closed class without an open, abstract, or interface modifier is a compilation error.
• The Solution: Emit a compiler error diagnostic when a class attempts to extend a non-open parent.
• Rust Implementation:
  When the parser encounters a class inheritance node (e.g., class MyIntent : Intent()), the engine will query the Indexer for the Intent superclass declaration. We will inspect its cached modifiers. If it lacks open/abstract/interface, we will emit: This type is final, so it cannot be inherited from.

---

📈 Current Progress & PR Tracking

To keep everything transparent and prevent any duplication of work, here is the current status of my open pull requests and active contributions:

• [OPEN PR] Mutability Enforcement: * PR: #137 feat: add val-reassignment diagnostics via live-CST walk
  • Spec: Flags assignment_expression mutations where the left-hand side identifier resolves to a read-only val property (is_writable == false).
• [OPEN PR] Code Generation & Refactoring: * PR: #134 feat:Generate code actions: getters, setters, and override methods
  • Spec: Introduces Quick Fix/Code Actions to automatically generate standard Boilerplate Getters, Setters, and unimplemented/override methods for class properties.
• [OPEN PR] Supertype Fallbacks: * PR: #132 feat:(generate_constructor): add resolver fallback chain for unindexed supertypes
  • Spec: Resolves empty constructor/initialization chains safely even when dealing with unindexed external supertypes.
• [COMPLETED] goToDefinition Scope Resolution Fix:
  • Status: Resolved in feat/kmp-codelens branch.
  • Spec: Fixed an edge case where invoking goToDefinition incorrectly jumped to a variable sharing the exact same name within the same file, even though it belonged to an entirely different, isolated scope.
• [NEW PR] KMP CodeLens + Diagnostics + Code Action: * Branch: feat/kmp-codelens
  • Status: CodeLens navigation for expect/actual across all KMP source sets, missing-actual diagnostics, one-click file creation code action, Neovim support, platform groups matching real KMP hierarchy. All 1201 tests pass, clippy clean.

---

Next Steps & Feedback

I will be rolling out the implementations for Smart Casts and Unused Diagnostics incrementally over the next couple of days.

@Hessesian — Please let me know your thoughts on this roadmap or if you have specific architectural preferences before I submit the next batch of PRs. Let's make this LSP absolute lightning! ⚡

[Hessesian]

Hi, amazing initiative, architecturaly I'm currently almost done with jvm sidecar that indexes libs, so for complicated analysis that would be first way to go, then if performance hits would be time to create complicated rust port. Some smart casting is already implemented with when on enums/sealed classes, so we might expand on that. LSP shouldn't modify code by itself, so that should be more of a cli thing, or a side tool leveraging lsp cli like some scripts already present in /contrib, thanks a lot!

[ulite-Amr]

Hi @Hessesian ,

Thanks for the awesome feedback and the architectural clarification! That makes perfect sense.

Here is how I’ll align my next steps with your vision:

1. Smart Casting: I’ll dive into your existing when evaluation logic for enums/sealed classes. Expanding on that setup to cover block-level scope tracking for basic if (obj is Type) smart casts feels like the perfect natural progression.
2. LSP Behavior & Dead Code: Completely agreed on the LSP constraint. I misworded that in the roadmap! I will strictly implement it as an editor warning (DiagnosticSeverity::HINT to grey it out) with a localized CodeAction quick-fix for the user to trigger manually. No autonomous code modification.
3. Java Sidecar Alignment: Congrats on the java-sidecar completion! I'll make sure to leverage it when pulling type metadata for external signatures instead of over-complicating the Rust layer early on.

I will start by drafting the KMP expect/actual CodeLens and expanding the Smart Casts based on your existing pattern. Looking forward to getting these out to you in the next few days! 🚀

[ulite-Amr]

@Hessesian

I will be closing the current Pull Requests for now.

After reviewing the recent feedback and taking a closer look at the overall design, I have decided to take a step back to thoroughly review the entire implementation, the refactoring, and the new KMP features.

My plan is to rewrite these features from scratch. This approach will allow me to properly address all the review comments, streamline the logic, and structure the code in a cleaner and more efficient manner from the ground up.

Thank you very much for your guidance and valuable feedback so far. I will open a new, more polished PR once the rewrite is ready.

Best regards,
[uliteAmr]

[ulite-Amr]

@Hessesian

Hey! First, I really appreciate you holding off on those roadmap features; that means a lot to me.
​Sorry for the long radio silence! I had some heavy real-life workload and offline commitments over the past weeks that kept me completely away from coding.
​I see you integrated GraalVM for the Kotlin sidecar—that's a clever way to handle the tree metadata! I'm catching up with the new setup this week and will start diving right back into the roadmap features we discussed. Excited to be back!