[Fikir] LSP Sunucusu — Derleyici Tamamlandığında Tam Yetenek Haritası (Tier 1-4) #91

New Issue

saqut · 2026-06-14T22:14:05+03:00

saqut commented

2026-06-14 22:14:05 +03:00

Giriş (Nedir, Neden Önemli?)

Bu issue'nun ilk hâli "derleyici bitmeden LSP'ye gerek yok, v0'da sadece hover/diagnostic yeter" diyordu. Ama soru şu: derleyici (Faz 0-4 + IR/VM) tamamen bittiğinde, "artık tam çalışan bir LSP istiyoruz" dersek ne lazım? Bu revizyon, LSP (Language Server Protocol, Dil Sunucusu Protokolü) yeteneklerini katmanlı bir kontrol listesi olarak ele alır: hangileri "olmazsa LSP'ye LSP denmez" (Tier 1), hangileri "kullanılabilirliği büyük sıçratır" (Tier 2), hangileri "modern/parlak ama sonra eklenebilir" (Tier 3), hangileri "v2/derin entegrasyon" (Tier 4).

Önkoşul (her tier'den önce): Artımlı derleme (incremental compilation) altyapısı — editördeki her tuş vuruşunda tüm projeyi/dosyayı baştan derlemek kabul edilemez gecikmeye yol açar. LSP sunucusu, AST + Symbol Table'ı bellekte tutmalı, sadece değişen dosyayı (ve onu import edenleri, #81-83) yeniden analiz etmelidir. Bu, "derleyici bir kütüphane olarak da kullanılabilir olmalı" (Faz 0-4'ün C++ API'sinin CLI'dan ayrı, gömülebilir bir arayüzü olması) anlamına gelir — büyük bir mimari karardır ve Tier 1'in önkoşuludur.

Tier 1 — "LSP" Denebilmesi İçin Olmazsa Olmaz

Yetenek	Hangi derleyici verisine dayanır
`textDocument/publishDiagnostics`	`DiagnosticEngine` (Faz 0) çıktısı — gerçek zamanlı kırmızı çizgiler
`textDocument/hover`	`ExpressionNode.resolvedType` (Faz 3) — değişkenin/ifadenin tipini gösterir
`textDocument/definition` (tanıma git)	`Symbol.definitionLoc` (Faz 2)
`textDocument/completion` (otomatik tamamlama)	Geçerli scope'taki semboller (Faz 2) + builtin kataloğu (#89) + anahtar kelimeler

Bu dördü olmadan editör deneyimi "düz metin editörü + harici terminal"den farksızdır — bu yüzden Tier 1, derleyici bitince hemen başlanacak iş.

Tier 2 — Kullanılabilirliği Büyük Sıçratır

Yetenek	Hangi derleyici verisine dayanır
`textDocument/references` (tüm kullanımları bul)	`Symbol.references` listesi (Faz 2) — zaten toplanıyor, sadece LSP'ye expose etmek yeterli
`textDocument/documentSymbol` (dosya özeti/outline)	Üst-seviye `FunctionDecl`/`StructDecl` listesi (AST)
`textDocument/rename` (güvenli yeniden adlandırma)	`references` listesi üzerinden toplu düzenleme — Faz 2'nin "iki geçişli toplama" doğruysa bu neredeyse bedava gelir
`textDocument/signatureHelp` (fonksiyon çağrısında parametre ipucu)	Fonksiyon sembolünün parametre tipleri (Faz 0 `Type`)

Tier 3 — Modern/Parlak, Sonradan Eklenebilir

Yetenek	Hangi derleyici verisine dayanır
`textDocument/semanticTokens`	AST düğüm tipi bazlı anlamsal renklendirme — statik TextMate gramerinden (#92) daha doğru (örn. bir `Identifier`'ın değişken mi fonksiyon mu olduğunu tipe göre renklendirir)
`textDocument/codeAction` (hızlı düzeltmeler)	#98 "akıllı diagnostic" + `saqut fix` (#107 Tier 2) — "did you mean X?" önerisini tek tıkla uygulama
`textDocument/formatting`	`saqut fmt` (#93) çıktısını doğrudan kullanır
`textDocument/inlayHint` (satır-içi tip ipuçları)	`resolvedType` — örn. `int x = 1;` satırının yanında soluk `: int` göstermek (ADR-010 literal adaptasyonunun görünür kanıtı)

Tier 4 — Derin Entegrasyon / v2

Yetenek	Hangi derleyici verisine dayanır
`workspace/symbol` (proje-geneli sembol arama)	Modül sistemi (#81-83) — tüm dosyaların sembol tabloları birleşik indekslenmeli
Call hierarchy (çağıran/çağrılan fonksiyonlar ağacı)	Fonksiyon çağrı grafiği — `CallExpressionNode` + `Symbol` ilişkisi
DAP (Debug Adapter Protocol) entegrasyonu	VM'in adım-adım çalışması + zaman-yolculuğu izleri (#94) — editörde "breakpoint koy, F10 ile adımla, değişkenleri izle"
Cross-file references / rename	Modül sistemi + `workspace/symbol`'ün üzerine inşa edilir

Açık Sorular

"Artımlı derleme" önkoşulu, Faz 0-4'ün C++ sınıflarının (örn. SymbolTable, DiagnosticEngine) tek dosyalık CLI çağrısı dışında, uzun ömürlü bir süreç içinde tekrar kullanılabilir şekilde tasarlanmasını gerektirir — bu mimari kısıt Faz 2-3 sırasında (sınıflar yazılırken) not edilmeli, sonradan eklemek çok daha maliyetli olur.
Tier 1-2'nin tamamı, esasen Faz 0-2'nin verilerini farklı bir protokolle dışa açmak — yani LSP'nin "ağır" kısmı zaten derleyicide var, kalan iş adaptör yazmak. Bu, kullanıcının "derleyici bitince LSP de hızlı gelir" beklentisini destekliyor.
DAP (Tier 4) en büyük yatırım — VM'in zaten "trace" (#94) yeteneği varsa, debugger bunun üzerine ince bir protokol katmanıdır; VM tasarımı (#74-78) sırasında "tek adım çalıştır" (step()) fonksiyonunun VM API'sinin parçası olması bu issue'yu önemli ölçüde kolaylaştırır.

İmza/Yorum: Önceki hâlde "v0'da gerek yok" denmişti — bu doğru ama eksikti. Doğru çerçeve: derleyici bittiğinde Tier 1, neredeyse "ücretsiz" gelir (veriler zaten orada); LSP'nin asıl maliyeti mimari önkoşulda (artımlı derleme) ve Tier 4'te (DAP) yoğunlaşır.

### Giriş (Nedir, Neden Önemli?) Bu issue'nun ilk hâli "derleyici bitmeden LSP'ye gerek yok, v0'da sadece hover/diagnostic yeter" diyordu. Ama soru şu: **derleyici (Faz 0-4 + IR/VM) tamamen bittiğinde**, "artık tam çalışan bir LSP istiyoruz" dersek **ne lazım**? Bu revizyon, LSP (Language Server Protocol, Dil Sunucusu Protokolü) yeteneklerini **katmanlı bir kontrol listesi** olarak ele alır: hangileri "olmazsa LSP'ye LSP denmez" (Tier 1), hangileri "kullanılabilirliği büyük sıçratır" (Tier 2), hangileri "modern/parlak ama sonra eklenebilir" (Tier 3), hangileri "v2/derin entegrasyon" (Tier 4). **Önkoşul (her tier'den önce):** Artımlı derleme (incremental compilation) altyapısı — editördeki her tuş vuruşunda tüm projeyi/dosyayı baştan derlemek kabul edilemez gecikmeye yol açar. LSP sunucusu, AST + Symbol Table'ı **bellekte tutmalı**, sadece değişen dosyayı (ve onu import edenleri, #81-83) yeniden analiz etmelidir. Bu, "derleyici bir kütüphane olarak da kullanılabilir olmalı" (Faz 0-4'ün C++ API'sinin CLI'dan ayrı, gömülebilir bir arayüzü olması) anlamına gelir — büyük bir mimari karardır ve **Tier 1'in önkoşuludur**. --- ### Tier 1 — "LSP" Denebilmesi İçin Olmazsa Olmaz | Yetenek | Hangi derleyici verisine dayanır | |---|---| | `textDocument/publishDiagnostics` | `DiagnosticEngine` (Faz 0) çıktısı — gerçek zamanlı kırmızı çizgiler | | `textDocument/hover` | `ExpressionNode.resolvedType` (Faz 3) — değişkenin/ifadenin tipini gösterir | | `textDocument/definition` (tanıma git) | `Symbol.definitionLoc` (Faz 2) | | `textDocument/completion` (otomatik tamamlama) | Geçerli scope'taki semboller (Faz 2) + builtin kataloğu (#89) + anahtar kelimeler | Bu dördü olmadan editör deneyimi "düz metin editörü + harici terminal"den farksızdır — bu yüzden **Tier 1, derleyici bitince hemen başlanacak iş**. ### Tier 2 — Kullanılabilirliği Büyük Sıçratır | Yetenek | Hangi derleyici verisine dayanır | |---|---| | `textDocument/references` (tüm kullanımları bul) | `Symbol.references` listesi (Faz 2) — zaten toplanıyor, sadece LSP'ye expose etmek yeterli | | `textDocument/documentSymbol` (dosya özeti/outline) | Üst-seviye `FunctionDecl`/`StructDecl` listesi (AST) | | `textDocument/rename` (güvenli yeniden adlandırma) | `references` listesi üzerinden toplu düzenleme — Faz 2'nin "iki geçişli toplama" doğruysa bu **neredeyse bedava** gelir | | `textDocument/signatureHelp` (fonksiyon çağrısında parametre ipucu) | Fonksiyon sembolünün parametre tipleri (Faz 0 `Type`) | ### Tier 3 — Modern/Parlak, Sonradan Eklenebilir | Yetenek | Hangi derleyici verisine dayanır | |---|---| | `textDocument/semanticTokens` | AST düğüm tipi bazlı **anlamsal** renklendirme — statik TextMate gramerinden (#92) daha doğru (örn. bir `Identifier`'ın değişken mi fonksiyon mu olduğunu **tipe göre** renklendirir) | | `textDocument/codeAction` (hızlı düzeltmeler) | #98 "akıllı diagnostic" + `saqut fix` (#107 Tier 2) — "did you mean X?" önerisini tek tıkla uygulama | | `textDocument/formatting` | `saqut fmt` (#93) çıktısını doğrudan kullanır | | `textDocument/inlayHint` (satır-içi tip ipuçları) | `resolvedType` — örn. `int x = 1;` satırının yanında soluk `: int` göstermek (ADR-010 literal adaptasyonunun **görünür** kanıtı) | ### Tier 4 — Derin Entegrasyon / v2 | Yetenek | Hangi derleyici verisine dayanır | |---|---| | `workspace/symbol` (proje-geneli sembol arama) | Modül sistemi (#81-83) — tüm dosyaların sembol tabloları birleşik indekslenmeli | | Call hierarchy (çağıran/çağrılan fonksiyonlar ağacı) | Fonksiyon çağrı grafiği — `CallExpressionNode` + `Symbol` ilişkisi | | **DAP (Debug Adapter Protocol)** entegrasyonu | VM'in adım-adım çalışması + zaman-yolculuğu izleri (#94) — editörde "breakpoint koy, F10 ile adımla, değişkenleri izle" | | Cross-file references / rename | Modül sistemi + `workspace/symbol`'ün üzerine inşa edilir | --- ### Açık Sorular - "Artımlı derleme" önkoşulu, Faz 0-4'ün C++ sınıflarının (örn. `SymbolTable`, `DiagnosticEngine`) **tek dosyalık CLI çağrısı** dışında, **uzun ömürlü bir süreç içinde tekrar kullanılabilir** şekilde tasarlanmasını gerektirir — bu mimari kısıt Faz 2-3 sırasında (sınıflar yazılırken) not edilmeli, sonradan eklemek çok daha maliyetli olur. - Tier 1-2'nin tamamı, esasen **Faz 0-2'nin verilerini farklı bir protokolle dışa açmak** — yani LSP'nin "ağır" kısmı zaten derleyicide var, kalan iş **adaptör** yazmak. Bu, kullanıcının "derleyici bitince LSP de hızlı gelir" beklentisini destekliyor. - DAP (Tier 4) en büyük yatırım — VM'in zaten "trace" (#94) yeteneği varsa, debugger bunun üzerine ince bir protokol katmanıdır; VM tasarımı (#74-78) sırasında "tek adım çalıştır" (`step()`) fonksiyonunun **VM API'sinin parçası** olması bu issue'yu önemli ölçüde kolaylaştırır. *İmza/Yorum:* Önceki hâlde "v0'da gerek yok" denmişti — bu doğru ama eksikti. Doğru çerçeve: **derleyici bittiğinde Tier 1, neredeyse "ücretsiz" gelir** (veriler zaten orada); LSP'nin asıl maliyeti mimari önkoşulda (artımlı derleme) ve Tier 4'te (DAP) yoğunlaşır.

saqut added the

fikir

tooling-lsp

labels 2026-06-14 22:14:05 +03:00

saqut referenced this issue

2026-06-14 22:26:30 +03:00

[Fikir] CLI Komut Seti — Tam Araç Zinciri Vizyonu (Tier 0-3: check/fmt/test/repl/build/pkg/...) #107

saqut changed title from ~~[Fikir] LSP (Language Server Protocol) Sunucusu Mimarisi~~ to [Fikir] LSP Sunucusu — Derleyici Tamamlandığında Tam Yetenek Haritası (Tier 1-4)

2026-06-14 22:37:47 +03:00

saqut referenced this issue

2026-06-14 22:38:39 +03:00

[Fikir] v1 → v2 Ekosistem Yol Haritası — Derleyici Bittikten Sonraki Bağımlılık Sırası #111

Sign in to join this conversation.