在上周，KCL 發(fā)布了 v0.4.6 版本，這個(gè)版本在語(yǔ)言、工具鏈、社區(qū)集成&擴(kuò)展支持等方面進(jìn)行了重點(diǎn)更新。本文包含 KCL IDE 插件的功能特性和 LSP 的介紹、KCL LSP Server 端的設(shè)計(jì)和實(shí)現(xiàn)以及未來(lái)的規(guī)劃和期望。

功能特性

在這次更新中，我們發(fā)布了全新的 KCL VS Code 插件，并且用 Rust 重寫(xiě)了 LSP 的 Server 端。我們提供了 IDE 中常用的代碼輔助功能，如高亮、跳轉(zhuǎn)、補(bǔ)全、Outline、懸停、錯(cuò)誤提示等。

• 高亮

• 補(bǔ)全

• Outline

• 懸停 & 跳轉(zhuǎn)

• 錯(cuò)誤/警告提示

歡迎到 https://kcl-lang.io/docs/tools/Ide/vs-code/ 了解更多

什么是 LSP？

在這次更新中，我們基于 LSP 實(shí)現(xiàn)了以上能力。LSP 指的是 Language Server Protocol，它是由微軟在 2016 年推出的一種用于編程語(yǔ)言工具的協(xié)議。借用一張圖，很容易就可以理解 LSP。

通過(guò) LSP ，編輯器和 IDE 可以通過(guò) JSON-RPC 通信協(xié)議與后端運(yùn)行的語(yǔ)言服務(wù)器(Server 端)進(jìn)行通信。語(yǔ)言服務(wù)器可以提供代碼分析、自動(dòng)補(bǔ)全、語(yǔ)法高亮、定義跳轉(zhuǎn)等功能?；?LSP，開(kāi)發(fā)者可以在不同的編輯器和 IDE 之間遷移，使得語(yǔ)言工具的開(kāi)發(fā)從 M(語(yǔ)言數(shù)量) * N(編輯器/IDE數(shù)量) 降低為 M + N。

為什么用Rust重寫(xiě)？

KCL 編譯器和其他工具最初由 Python 實(shí)現(xiàn)，因?yàn)樾阅茉?，我們?Rust 語(yǔ)言重寫(xiě)了編譯器（性能提升 40 倍！我們用 Rust 重寫(xiě)了自己的項(xiàng)目）。在此之后，我們使用 Rust 逐步重寫(xiě)了 KCL 的其他工具，如測(cè)試工具、Format 工具等。在這次更新中，我們用 Rust 重寫(xiě)了 LSP Server 端，其主要考慮因素也是性能。

過(guò)去，Python 版本的 Server 端在處理一些復(fù)雜的場(chǎng)景（編譯文件數(shù)量超過(guò)200個(gè)）時(shí)，處理一個(gè)跳轉(zhuǎn)的請(qǐng)求，Server 端從接收到請(qǐng)求到計(jì)算結(jié)果并響應(yīng)，時(shí)間長(zhǎng)達(dá) 6 秒以上，幾乎是不可用狀態(tài)。由于 Server 端的實(shí)現(xiàn)主要基于語(yǔ)言編譯器前中端的詞法解析和語(yǔ)義分析，在我們使用 Rust 重寫(xiě)以后，這部分性能分別提升了 20 和 40 倍， 帶來(lái)的顯著結(jié)果就是 Server 端的響應(yīng)時(shí)間得到了巨大提升，對(duì)于同樣的場(chǎng)景，響應(yīng)時(shí)間縮短至 100 毫秒左右。而對(duì)于一些簡(jiǎn)單的場(chǎng)景，響應(yīng)時(shí)間只有幾毫秒，做到了用戶無(wú)感。

KCL LSP Server的設(shè)計(jì)與實(shí)現(xiàn)

KCL LSP Server 的設(shè)計(jì)如下圖所示：

主要流程可以分為幾個(gè)階段：

1. 建立連接，初始化 LSP 能力。在 IDE 的 Client 端，打開(kāi)特定文件（KCL的 *.k）時(shí)，IDE 會(huì)啟動(dòng)本地的 kcl_language_server 二進(jìn)制文件，啟動(dòng) Server 端。這個(gè)文件與 KCL 一起發(fā)布，并安裝在 KCL 的 bin 目錄下。Server 啟動(dòng)后會(huì)建立 standard IO 的 Connection，并等待 Client 發(fā)送的初始化請(qǐng)求。Server 端接收初始化請(qǐng)求后會(huì)定義 Server 端信息和能力，并返回給 Client，以此完成 LSP 的初始化連接。
2. 建立連接后，Server 端會(huì)啟動(dòng)一個(gè)輪詢函數(shù)，不斷接收來(lái)自 Client 的 LSP Message，例如 Notification（打開(kāi)/關(guān)閉/變更/刪除文件等）和 Request（跳轉(zhuǎn)、懸停等），以及來(lái)自 Server 端自身的 Task。并統(tǒng)一封裝成事件（Event）交給下一步處理。
3. 對(duì)于各種事件，按照以下步驟處理：

///Handlesaneventfromoneofthemanysourcesthatthelanguageserversubscribesto.
fnhandle_event(&mutself,event:Event)->anyhow::Result<()>{
//1.Processtheincomingevent
matchevent{
Event::Task(task)=>self.handle_task(task)?,
Event::Lsp(msg)=>matchmsg{
lsp_server::Request(req)=>self.on_request(req,start_time)?,
lsp_server::Notification(not)=>self.on_notification(not)?,
_=>{}
},
};

//2.Processchanges
letstate_changed:bool=self.process_vfs_changes();

//3.HandleDiagnostics
ifstate_changed{
letmutsnapshot=self.snapshot();
lettask_sender=self.task_sender.clone();
//Spawnthediagnosticsinthethreadpool
self.thread_pool.execute(move||{
 handle_diagnostics(snapshot, task_sender)？;
});
}

Ok(())
}

3.1 任務(wù)分發(fā)：根據(jù)任務(wù)類型，做函數(shù)分發(fā)。在子函數(shù)中，會(huì)進(jìn)一步基于 Request 或 Notification 的類型繼續(xù)分發(fā)到最終的處理函數(shù)中，如處理文件變更、處理跳轉(zhuǎn)請(qǐng)求等。這些函數(shù)會(huì)根據(jù)基于編譯器中前端編譯出的語(yǔ)義模型（AST，符號(hào)表，錯(cuò)誤信息等）做分析，計(jì)算生成對(duì)應(yīng)的 Response（如跳轉(zhuǎn)請(qǐng)求的目標(biāo)位置）。

3.2 處理變更：用戶在修改代碼或更改文件時(shí)，會(huì)發(fā)送對(duì)應(yīng)的 Notification。在前一步的處理中，會(huì)將變更保存在虛擬文件系統(tǒng)（VFS）中。Server 端會(huì)根據(jù)新的源代碼，進(jìn)行重新編譯，保存新的語(yǔ)義模型，以供下一個(gè)請(qǐng)求做處理。

3.3 錯(cuò)誤處理：這里的錯(cuò)誤并非指 Server 端的運(yùn)行錯(cuò)誤，而是代碼編譯中的語(yǔ)法、語(yǔ)義錯(cuò)誤，編譯警告等。Client 端并沒(méi)有對(duì)應(yīng)的請(qǐng)求類型來(lái)請(qǐng)求這些錯(cuò)誤，而是由 Server 端主動(dòng)發(fā)送 Diagnostics。因此，在發(fā)生變更后，同步地將錯(cuò)誤信息更新至 Client 端。

遇到的問(wèn)題

1.為什么需要虛擬文件系統(tǒng)？

在最初的設(shè)計(jì)中，并沒(méi)有考慮使用虛擬文件系統(tǒng)。我們每次從文件系統(tǒng)中獲取源代碼，進(jìn)行編譯和分析。對(duì)于一些“靜態(tài)”的任務(wù)，如跳轉(zhuǎn)，可以在變更代碼后保存到文件系統(tǒng)，然后再進(jìn)行跳轉(zhuǎn)的操作。配合到 VS Code 的自動(dòng)保存功能，體驗(yàn)上并沒(méi)有明顯的差距。但對(duì)于代碼補(bǔ)全這一功能，IDE 中輸入的補(bǔ)全trigger（如 “.”）會(huì)觸發(fā)文件變更的通知和代碼補(bǔ)全的請(qǐng)求，但對(duì)應(yīng)的代碼還未保存到文件系統(tǒng)中，編譯后的語(yǔ)義模型無(wú)法做對(duì)應(yīng)的分析。因此，我們借助 Rust Analyzer 對(duì)應(yīng)的 vfs 的create，在 Server 端引入了虛擬文件系統(tǒng)，將編譯的入口從文件路徑變?yōu)榱?source code。Client 端輸入代碼后，文件變更的通知會(huì)先更新虛擬文件系統(tǒng)，重新編譯文件，生成新的語(yǔ)義模型，然后再處理補(bǔ)全請(qǐng)求。

2. 如何處理不完整的代碼？

我們遇到的另一個(gè)比較大的問(wèn)題是如何處理不完整的代碼。同樣的，對(duì)于跳轉(zhuǎn)這類“靜態(tài)”的任務(wù)，可以假定代碼是完整、正確的。但對(duì)于補(bǔ)全操作，如以下代碼，希望在輸入.后，補(bǔ)全字符串的函數(shù)。對(duì)于編譯流程，第二行實(shí)際上是不完整的代碼，無(wú)法編譯出正常的 AST 樹(shù)。

s:str="hellokcl"
len=s.

為此，我們?cè)?KCL 的編譯中實(shí)現(xiàn)了語(yǔ)法和語(yǔ)義上的多種錯(cuò)誤恢復(fù)，保證編譯過(guò)程始終能產(chǎn)生完整的 AST 和符號(hào)表。在這個(gè)例子中，我們新增了一個(gè)表示空的 AST 節(jié)點(diǎn)作為占位符，使得第二行能夠生成完整的 AST。在處理補(bǔ)全的請(qǐng)求時(shí)，會(huì)根據(jù) s 的類型和其他語(yǔ)義信息，補(bǔ)全函數(shù)名、schema attr 或 pkg 中定義的 schema 名。

Rust Analyzer architecture:

Architecture Invariant: parsing never fails, the parser produces (T, Vec) rather than Result.

總結(jié)與展望

KCL 的 IDE 插件目前已經(jīng)實(shí)現(xiàn)高亮、跳轉(zhuǎn)、補(bǔ)全、Outline、懸停、錯(cuò)誤提示等功能。這些功能提升了 KCL 用戶的開(kāi)發(fā)效率。然而，作為一款 IDE 插件，它的功能還不夠完整。在未來(lái)的開(kāi)發(fā)中，我們會(huì)繼續(xù)完善，未來(lái)的工作有以下幾個(gè)方向：

1. 更多的語(yǔ)言能力：提供更多的功能，如代碼重構(gòu)，錯(cuò)誤的quick fix，代碼 fmt等，進(jìn)一步完善功能，提升開(kāi)發(fā)效率
2. 更多的 IDE 接入：目前，KCL 雖然提供了 LSP，只接入了 VS Code，未來(lái)會(huì)基于 LSP 的能力為 KCL 用戶提供更多選擇。
3. AI 能力的集成：目前，ChatGPT 風(fēng)靡全網(wǎng)，各行各業(yè)都在關(guān)注。我們也在探索 AI×KCL 的結(jié)合，提供更智能的研發(fā)體驗(yàn)。總之，我們會(huì)繼續(xù)完善和優(yōu)化 KCL 的 IDE 插件，讓它更加成熟和實(shí)用。為KCL用戶帶來(lái)更加方便和高效的開(kāi)發(fā)體驗(yàn)。