JETLS.jl ─ A New Language Server for Julia

Transcript

1. JETLS.jl: A New Language Server for Julia JuliaLang Japan 2025 Yuchi Yamaguchi, @abap34
2. About Me イマココ ここの 8 階に 研究室があります 東京科学大 情報理工学院情報工学系 渡部研 B4 (https://www.psg.comp.isct.ac.jp/) プログラミング言語の研究をしています 形式手法，コンパイラ最適化など 機械学習も好き Julia 歴 7 年弱くらい GSoC ‘25 (JuliaLang) ─ JETLS.jl の機能開発 Yuchi Yamaguchi (山口 悠地), @abap34 https://www.abap34.com @abap34 @abap34
3. エディタにおける開発支援 みんな使っているはず: 補完出したり 赤線引いたりしてくれるやつ ▶︎ エディタにおける開発支援
4. Analyzer エディタ ② 6行3列目の 補完候補を教えて ④ 補完候補は `hello`, `help` だよ ① Tab キーを押す ③ ええと，この位置で 生存しうる 変数の集合は... ⑤ 補完候補を表示 「補完」が動くまで 補完したいな
5. Language Server とは ❓ ⇨ Language Server Protocl (LSP) によってエディタと通信して開発支援を行うサーバ． https://microsoft.github.io/language-server-protocol/ Language Server とは？
6. LanguageServer ① なんらかの 支援をリクエスト ⑤ 結果をレンダする エディタ LanguageServer とは ❓ ⇨ Language Server Protocol (LSP) によってエディタと通信して開発支援を行うサーバ． https://microsoft.github.io/language-server-protocol/ ええと，ここを解析すると... ここのやりとりの プロトコル 解析しているやつの名前が 「LanguageServer」 ここについては関与しない Language Server Protocol の担当範囲 ここのこれって どうなの それはこれだよ
7. LSP は広く支持されている！ ✅ Visual Studio Code ✅ Vim / NeoVim ✅ Intelij IDEA ✅ Jupyter Lab ✅ Helix ✅ Zed ✅ Notepad++ ✅ Sublime Text ✅ Emacs 現代の主要なコードエディタはほぼすべて なんらかの形で LSP をサポート． LS のクオリティが その言語の開発体験に直結する. (貧弱な LS しかない言語は敬遠されるし， 強力な LS が提供されている言語は人気が出る) Language Server の重要性
8. (貧弱な LS しかない言語は敬遠されるし， 強力な LS が提供されている言語は人気が出る) じゃあ Julia はどうなのか？ https://github.com/julia-vscode/LanguageServer.jl 資料作成日: 2025/11/18 julia-vscode/ LanguageServer.jl ⭐️ 399 Star ⇨ LanguageServer.jl
9. LanguageServer.jl はすばらしい！ ⇨ が... 定義にマクロを含むコードをうまく解析できない 高度な解析を含むエラーの検知をしない設計 メンテナンスコストが増大してしまっていた LanguageServer.jl (LS 開発はとても大変だし，Julia プログラマの生産性向上に間違いなく寄与してきた)
10. ⇨ 定義にマクロを含むコードをうまく解析できない 高度な解析を含むエラーの検知をしない設計 メンテナンスコストが増大してしまっていた (Julia ではこのような書き方が多用される) LanguageServer.jl の課題点 という変数が API_TOKEN このマクロを展開しないと 定義されているかわからない
11. ⇨ 定義にマクロを含むコードをうまく解析できない 高度な解析を含むエラーの検知をしない設計 メンテナンスコストが増大してしまっていた LanguageServer.jl の課題点 zero(Any) 最終的に が呼び出されてここでエラーになる
12. ⇨ 定義にマクロを含むコードをうまく解析できない 高度な解析を含むエラーの検知をしない設計 メンテナンスコストが増大してしまっていた LanguageServer.jl の課題点
13. わたしたちは Julia の 新しい Language Server (https://github.com/aviatesk/JETLS.jl） JETLS.jl を開発しています！ @aviatesk,@mlechu,@abap34 (東京科学大) (JuliaHub) など (JuliaHub) ✔️ JETLS.jl は マクロを含むようなプログラムに対しても問題なく解析を行える 高度な型解析を含む強力な静的検査を備えた LS を少ないメンテナンスコストで実現することを目指しています！ ✔️ 特に大規模なコードベースで作業する Julia プログラマが より安全でパフォーマンスが良いプログラムを記述することを 強力に支援します！ JETLS.jl
14. LS の開発コスト 主張: LS 開発は大変.　 😢 なぜ？ そもそも LS はどう実現されるのか？ ⇨
15. 例) SyntaxError の赤線を引く機能を実現する ふつうにその言語のコンパイラが使っている パーサを使えばいんじゃないの？ Language Server の実現方法を考える
16. LS のためのパーサに求められる要件が コンパイラにあるパーサで必ずしも 達成されているとは限らない！ Language Server の実現方法を考える
17. Language Server におけるパース ので... 差分が小さいが大きな コードベースを つぎつぎにパースする いちいち全部パースしなくても 差分が小さいことを利用して 実用的な時間でパースしたい 壊れているプログラムからでもなるべく 有効な情報を得られるようにしたい 「壊れている位置」として有用な情報を 提供したい プログラムは基本的に 壊れている ので... 構文エラーなら 「どこが壊れているか」 という問いに答えはないけど 「こういう意図かな？」 を汲んで欲しい
18. 1行目にエラー 既存パーサのエラー位置報告 が余分... で，一行目のどこの？？ ]
19. v 1.12 では： 既存パーサのエラー位置報告 「バイトレベル」の 位置が出て どこかわかる！
20. 他言語での類似事例: Ruby の Prism JuliaSyntax.jl の開発によるパーサの改善 JuliaSyntax.jl の開発 + デフォルトパーサに！ (boot 後のユーザコードの) + メンテナンス性の向上 + より他のパッケージから使いやすく (JETLS でも利用) + SyntaxError の位置報告の改善 + エラートレランス
21. 一行目のどこの？ UndefVarError ... Python は教えてくれるのに！ コンパイラフロントエンドの改善は続くよどこまでも
22. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 using LinearAlgebra torus = [[(2 + cos(v)) * cos(u), (2 + cos(v)) * sin(u), sin(v)] for i in 0:29 for u in [2pi*i/30] for j in 0:29 for v in [2pi*j/30]] Rx(t) = [1 0 0; 0 cos(t) -sin(t); 0 sin(t) cos(t)] Ry(t) = [cos(t) 0 sin(t); 0 1 0; -sin(t) 0 cos(t)] Rz(t) = [cos(t) -sin(t) 0; sin(t) cos(t) 0; 0 0 1] for frame in 1:300 t = frame * 0.03 screen, zbuf = fill(' ', 25, 80), fill(Inf, 25, 80) for v in torus r = Rz(t) * Ry(t*0.7) * Rx(t*0.5) * v z = r[3] + 5 x, y = Int(round(r[1]/z*35+40)), Int(round(r[2]/z*20+12)) if 1 <= x <= 80 && 1 <= y <= 25 && z < zbuf[y,x] screen[y,x] = ".,:;ox%#@"[min(9, max(1, Int(floor(z))))] zbuf[y,x] = z end end print("\033[H\033[J") foreach(row -> println(join(row)), eachrow(screen)) sleep(0.03) end S o u r c e ( S t r i n g ) E x p r I n t e r p r e t e r / C o m p i l e r J S . S y n t a x T r e e C o d e I n f o call-i ref 3 + 5 r = z 1 z = r[3] + 5 なんやかんや なんやかんや なんやかんや なんやかんや ⇨ なんやかんや なんやかんや なんやかんや ⇨ ※ とりうる遷移やデータ構造を正確に反映・網羅したものではないです. 省略された遷移・データ構造がたくさんあります． 【現状の Julia コンパイラでは lowering 後に正確な位置情報は保持されていない】 闇の世界 (行だけ保持) 正確に位置を保持 コンパイラフロントエンドの改善は続くよどこまでも
23. S o u r c e ( S t r i n g ) E x p r I n t e r p r e t e r / C o m p i l e r J S . S y n t a x T r e e C o d e I n f o なんやかんや なんやかんや なんやかんや Work in Progress... JuliaLowering.jl + メンテナンス性の向上 + マクロの利便性向上 + 使いやすさの向上 + より進んだフェーズでも 正確にエラーを出す この辺りを担当 JuliaLowering.jl によるエラー報告の改善 ここに正確な位置情報がつく未来が来るかも？
24. JET.jl aviatesk/ JETLS.jl における 静的検査で重要かつ核心的な役割 Julia コンパイラの解析インフラを利用 さまざまなエラーを静的に検出可能 高度な型解析が必要なエラーを検出可能 📝 コンパイラフロントエンドによる処理が終わったあとにさまざまな解析を行う zero(Any) が呼び出されることと に対して Type{Any} zero が実装されていないことを検知 解析ルーチンの開発
25. ✔️ JETLS の戦略: Julia コンパイラインフラと資産を共有 してメンテナンス性を高める (JuliaSyntax.jl, JuliaLowering.jl, JET.jl, Revise.jl ...) 最新 Julia コンパイラフロントエンド x JETLS LanguageServer.jl の メンテナンスコストの増大 に対して...
26. rust-analyzer/rowan rust-lang/rust-analyzer/crates/parser rust-lang/rust-analyzer/crates/hir rust-lang/rust-analyzer/crates/hir-ty .... 独自の IR 独自の 型推論 独自の ... 独自の Syntax Tree 独自の パーサ 他の LS はどうか？ 例) rust-analyzer ⇨ (同様にコンパイラインフラを活用しているものが多いが...) LS は独自のコンポーネントを持つべきか？ ✔️ JETLS の戦略: Julia コンパイラインフラと資産を共有 してメンテナンス性を高める (JuliaSyntax.jl, JuliaLowering.jl, JET.jl, Revise.jl ...)
27. ふたたび: LS は独自のコンポーネントを持つべきか？ (標準的な) コンパイラの コンポーネントに求められるもの LS に求められるもの ≠ 必ずしも一致しない 独自のコンポーネントの開発によって LS の信頼性・パフォーマンスが向上する 可能性はある ⇨
28. More software projects have gone awry for lack of calendar time than for all other causes combined. Frederick Phillips Brooks もしも LS を開発するエンジニアが 100 万人いるなら おそらく全て独自のものを開発したほうがいい． ただ，メンテナンスコストの削減によって 長期的に LS を維持するほうがユーザにとって 利益になるはず！ LS は独自のコンポーネントを持つべきか？ ✔️ 一方で開発コストは跳ね上がる． この方向をうまく 進めていくには？
29. LS ・Julia コンパイラの課題と未来 解析インフラがアドホックに 拡張されていて様々な需要に 応える拡張が困難 コンパイラの挙動が頻繁に 変更されて追従が困難 or 仕様が不明瞭 コンパイラの安定的でない部分に依存し ているため，バージョンごとに実装を分 けたり変更に追従するコストが生まれて しまい，本末転倒． 安定的な API はコンパイラを利用する 様々なパッケージにも大きな利益になる はず． コンパイラの開発・実行速度を落とすことなくこれらを実現して コンパイラ本体と LS 両方のクオリティを上げていきたい！ Julia コンパイラの解析ルーチンは 抽象解釈 (abstract interpretation) に基づいている． うまく設計できればさまざまな解析の 「ソルバ」として Julia コンパイラが 利用できるはず． いろんな最適化問題が 実は線形計画法に 落ちるので強力な LP ソルバがあるとハッピー not 抽象解釈界隈の人向けの 例え: 他にも細かいトピックは たくさん... 安全なロード・マクロ展開のための技術 エフェクトの解析? Wasm Runtime によるサンドボックス化? よりユーザの意図を汲んだエラー報告 キャッシュインフラ リモートキャッシュのサポート 型解析結果をどう表示するべきか 現在の vscode 拡張との統合 ... 各種自動微分ライブラリ， Revise.jl, JET.jl など
30. check it out !