自作言語コンパイラをウェブブラウザで動くようにした話

はじめに

自作言語コンパイラがウェブブラウザで動くと面白いという発想でえいやっとした話です。

自作言語コンパイラの概要

既存の言語への理解を深めるためにoriglangという仮題で自作言語のコンパイラを開発しています。詳細は GitHubレポジトリをご覧ください。

ウェブブラウザで動かすための技術選定

ウェブブラウザのサポート対象はモダンブラウザ (Internet Explorerや古いSafariを除いたブラウザの総称) としました。理由としては古いブラウザをサポートする特別の理由がないからです。

そして、モダンブラウザのみに限定するならJavaScript (やasm.js) よりWebAssemblyだろうという結論に至りました。その理由として、次の3点が挙げられます。

1. WebAssemblyは静的型付け
2. JavaScriptは人間に読めるのでバンドルサイズが大きい
3. WebAssemblyのほうが保証されている性質が多いので、よりよい最適化が期待できる

この記事を書くにあたって事後調査をしたらasm.jsはコーナーケースで実装の差がある という記事を発見しました。なのでasm.jsを使わなかったのは正解なんだと思います。

クレートの分割

コンパイラは1つのクレートの中にあるサブモジュール群から構成されていましたが、それらのサブモジュール群をlibクレートとしてそれぞれ別々のクレートに分割しました。理由は2つあります：

1. Rustのコンパイラを見習った
2. #[cfg] で実装を切り替えるのが手間だと思っていた

こうすることで原因が切り分けやすくなるのでやって良かったと思います。実際は次のように分割しました。

• origlang-ast - AST (抽象構文木) の構造のモデリング
• origlang-cli - OS上におけるツールチェインのフロントエンド
• origlang-compiler - レキサー、パーサー、型チェック
• origlang-runtime - スコープや中間コードなど、実行時の情報の格納
• origlang-platform - プラットフォーム事情のカプセル化
• origlang-typesystem - 型システムのモデル

次にuseがどこを指しているかわからないと言ってくるので、適宜サブモジュールのCargo.tomlに依存を追加しながらstructや関数の可視性を調整します。

ルートディレクトリでcargo cを実行し、コンパイルが通ればOKです。

WebAssembly用サブモジュールの追加

次にWebAssembly用のサブモジュールを追加します。ここではoriglang-interopと命名しました。

Cargo.tomlを開いて、次のスニペットを追記します¹：

Cargo.toml

[lib]
crate-type = ["cdylib"]

[dependencies]
# 必要に応じてバージョンを変えてください
wasm-bindgen = "0.2.74"

lib.rsにかかれているであろうコードを全て削除します。Hello Worldを見ながら適切なシグネチャでJavaScript側に後で作る関数を宣言します。宣言するためにはwasm-bindgenの#[wasm_bindgen]というproc-macro²を使います。これをextern³節につけるとJavaScript側で宣言されている関数を宣言し、pub fn⁴につけるとWebAssembly側で宣言する関数を宣言します。

サブモジュール側で適切にコンパイラをインスタンス化してコンパイルを開始する関数を呼びます。WebAssemblyは標準出力を持たないので、もし式の結果を出力することがあれば都度JavaScriptに委譲します。実際の実装はこうなりました：

これをビルドするためにwasm-packというツールをインストールする必要があります。

フロントエンドの作成

簡単に⁵フロントエンドを作っておきます。extern節につけた#[wasm_bindgen]と同じ名前、互換性のあるシグネチャを受理できる関数を作っておきましょう。また、それよりも前の<script>でwasm-scriptから出力されたoriglang_interop.jsをtype="module"として、origlang_interop_bg.wasmをtype="application/wasm"としてそれぞれ読み込んでおきましょう。

以下に例を示します。

ローカルで立ち上げるHTTPサーバー用のサブモジュールの追加

最近のブラウザはCORSの制限が厳しいので、それを避けるために手元で動かすことを想定したHTTPサーバーを立ち上げるサブモジュールを新しく作ります。ここではoriglang-interop-frontend-webserverと命名しました。使うクレートは何でもいいですが、actix-webとactix-filesを使いました。

以下に実際の実装を示します。

一通り立ち上がることが確認できたら、次へ進みます。

GitHub Actionsの設定

wasm-packのインストール

wasm-packはHosted runnerに入っていないので、自分でインストールする必要があります。とりあえず一行で済む

cargo install wasm-pack

で入れました。

cargo install wasm-pack が遅い

しかし、cargo installは何も設定を渡さないとリリースモードでソースからコンパイルを行います。それは許容できなかったので--debugをつけたのですがあまり有意な縮み方にはなりませんでした。

そこで、GitHubのReleasesからすでにビルドされたバイナリを持ってきて動かすことにしました。*.tar.xzという名前から、適切に解凍してやる必要があると推測できます⁶。また、今回必要なのは実行ファイルのみなので実行ファイルのみを解凍します。

wasm-pack が見つからない？

最初はwasm-packが見つからないと言われました。実行ファイルをフルパスで指定しなかったときに見つからなかったと言われる原因の99.99%はその実行ファイル (を含んでいるディレクトリ) がPATHに通ってないからです。mv wasm-pack /usr/local/binとして解決しました。

WindowsだとPowerShellと解釈される

origlangのworkflowでは過去の失敗からUbuntuとWindowsの両方においてコンパイルが通るかチェックしていますが、WebAssemblyをビルドする変更を入れるとCIが失敗するようになってしまいました。これは好ましくありません⁷。

その筆頭としてWindowsのrunnerが直書きのスクリプトをPowerShellとして解釈し、失敗するという問題がありました。これはshell: bashとして明示的にインタプリタを指定することで解消しました。

Windowsのbashには/usr/local/bin がない

なぜかははっきりしていませんが、Windowsのbashは/usr/local/binがないようです。仕方がないのでもし移動に失敗した場合は/usr/binへの移動を試すことにしました。

WindowsのbashはLinux向けにコンパイルされたバイナリを解釈できない

当たり前といえば当たり前かも知れませんが、WindowsのbashはLinux向けにコンパイルされたバイナリを解釈できないようです。そのため、適切なターゲットトリプルをworkflowのmatrixに持たせ、ダウンロードするURLを変更するようにしました。

GitHub Actionsのworkflowにおけるmatrixがデカルト積を生成する

workflowのYAMLにmatrixという名前でキーを指定すると、workflowに渡る値の組み合わせを切り替えられる仕組みがあります (GitHub)。これ自体はいい機能です。デフォルトで設定の値のデカルト積 (Wikipedia 日本語版の記事) を生成し、その組み合わせの全てを試す実装になっています。今回のワークフローにおいては、これは望ましい実装ではありません。なぜならWindowsがLinux向けにコンパイルされたバイナリを解釈しようとしたり、その逆が起きたりするためです。

各設定項目をまとめたオブジェクトの配列をmatrixに渡すと正しく解釈されず、workflowの実行自体がスキップされてしまいました。幸いにも、matrixの代わりにincludeを指定することでデカルト積を生成せずに各設定の組み合わせを追加することができたのでこれを採用しました。

実行ファイルに拡張子が付いていることがある

wasm-packに含まれている実行ファイルは、Linux向けにコンパイルされたものだと拡張子が付いていません。一方で、Windows向けにコンパイルされたものは拡張子が付いています。これは文化圏の差ですが、すっかり忘れていました。

実行ファイルの名前もworkflowのmatrixに持たせることで解消しました。

NGシーン: build.rs の内部から wasm-pack

当初はoriglang-interop の build.rsからwasm-packを実行すればCIでも手元でも同じような実装を繰り返さなくて済むと考えていたことがありました。しかし、これはうまく行きませんでした。なぜかはわかっていませんが、wasm-packの出力から推察される理由として、wasm-pack自体がcargo buildに相当することをやっていることが挙げられます。cargo build自体はビルドに対する専有ロックを取得しますが、取得できなかった場合は取得できるまで実行がブロックされます。

それによって、次のようなデッドロックが生まれてしまったと推察できます。

パッケージ	先に進むための条件
origlang	origlang-interopのビルドが終わること
origlang-interop	wasm-packによるビルドが終わること
(wasm-pack)	origlangが抱えているビルドのロックが開放されること

三すくみです。これはどう頑張っても無限ループです。

build.rsによるアプローチを諦めて、build.shからwasm-packを実行して都度ビルドする運用に切り替えたら解消しました。

おわりに

オチは特にありません。

1. もし忘れてもwasm-packがエラーで指示してくるので忘れても大丈夫です ↩

2. アノテーションみたいなものです。 ↩

3. ABIを省略するとextern "C"と同様の意味になります。今回は私が「JavaScriptなのにextern "C"は実装の都合なのでexternを選択する」という選択をしたので、このまま省略しておきます ↩

4. pubでない場合、サポートされていないというエラーが出てコンパイルできません ↩

5. 必要最低限のインターフェースしか持たない実装 ↩

6. と言っても、私がやる必要があるのは tar xf hoge.tar.xz だけです ↩

7. 2つ理由があります。1つ目はビルドが失敗するたびに Notification に通知されて大変愉快なことになるということです。2つ目はそしてレポジトリのステータスとして部分的であってもビルドが失敗しているのは見栄えが悪いと私が考えていることです。 ↩