今月の活動 (HSP3アナライザーミニなど)
- 前回 (2021-04-30) https://vain0x.github.io/blog/2021-04-30/diary/
ミローネ言語
https://github.com/vain0x/milone-lang
気軽にビルドしたり実行したりするためのサブコマンドを用意しようとしている。コマンドラインの解析とかCでファイルシステムを触るのとかがめんどくさくて、あまり進んでない。
HSP3アナライザーミニ
https://github.com/vain0x/hsp3-ginger/tree/0ec7c6c/hsp3-analyzer-mini
いくつか機能を足した。
formatting
空白や字下げのフォーマッティングを実装した。
HSPは文の途中で改行できないので、逆にフォーマッティングの実装で悩まなくて済んだ。
code action
コードアクション (コードを自動で変更する機能) の例として、rust-analyzerにあって地味に便利な、カンマの両側を交換するアクションを書いた。
構文木が異型な (ノードごとに異なる型になっている) ので、代わりにビジターを使ったりトークン列を触ったりしていて、実装がぎこちない。(rust-analyzerでのflip_commaの実装は24行。)
diagnostics
エラー報告の機能の例として、変数を受け取るパラメータに明らかに変数ではないものを渡している部分をエラーにする機能を実装した。
エラーを報告する機能は、解析に誤りがあると偽陽性 (ほんとうは正しいのにエラーになってしまう) が発生してめんどくさい。 そしてhamは仕組み上、必ずしも正しくスクリプトを解析できない。
- 誤った解析になる原因の1つは、コンパイルの起点 (エントリーポイント) が分からないこと。
#include経由で読み込まれる前提のスクリプトファイルは単独では正常に動作しない。どこでincludeされたかによって意味が変わる。 - 2つ目の理由はdefineによるマクロ。マクロの挙動の再実装は難しいので、いまのところマクロの展開は全く行われない。
- 3つ目の理由はコンパイル時の条件分岐 (
#if)。ファイルがどこでincludeされたかに依存するので処理できてない。
そういうわけで、エラーを報告する機能はエントリーポイントを指定したときだけ有効にする。いまは ginger.txt という名前のファイルにエントリーポイントとなるファイル名を書くと有効化される。プロジェクトファイルのようなものだけど、スクリプトファイル単体で動作するのがHSPのよさの1つなので、この仕様はよくないと思ってる。
ウォッチ
デバッグ中にLSPサーバーを自動で再起動するようになった。デバッグ用のVSCodeを開閉しなくてもよくなった。LSPサーバーの実行ファイルへの変更を監視して、変更があったらLSPクライアントを停止→再起動するという仕組み。
起動中の実行ファイルに書き込むことはできないから、別の位置にコピーしてから起動するようにしている。(なぜか分からないけどWindowsだと元の実行ファイルがロックされていて、このあたりがうまくいってなさそう。)
ginger
出力が文字化けする問題があったので直した。
標準出力のコードページが932になっていたのを、アプリ側で65001に変更することで直ったっぽい。たぶん以前のバージョンを作ったときはWindowsのUTF-8にする機能を有効にしていたから、文字化けしなかったのかもしれない。
knowbug
変更があった行を強調表示する機能を足そうと思ったけど、ListViewの項目の色を行ごとに変えるにはオーナードローが必要と聞いてやめた……
cutil
https://github.com/vain0x/cutil
Rustの標準ライブラリみたいな、spanベースの文字列とか、allocator-awareなコレクションとかがC言語にもほしいと一瞬思ったやつ。
rust-analyzerの少額スポンサーになった
https://github.com/sponsors/rust-analyzer?sc=t&sp=vain0x
少額ながらrust-analyzer (RustのIDE機能を開発するOSS) のスポンサーになった。
rust-analyzer (+ VSCode) は私が知るかぎり機能面でも性能面でも最高クラスのIDEであり、日々便利に使わせてもらってるし、設計や実装において参考にしたい面がたくさんある。