🚀 VS Code で で入手しましょう!

WebAssembly を使用した拡張機能開発 - パート 2

2024 年 6 月 7 日 Dirk Bäumer 著

WebAssembly を使用した拡張機能開発に関する前回のブログ記事では、コンポーネントモデルを使用して WebAssembly コードを Visual Studio Code 拡張機能に統合する方法を説明しました。今回のブログ記事では、2 つの独立した追加のユースケースに焦点を当てます。(a) 拡張機能ホストのメインスレッドのブロックを回避するために、ワーカーで WebAssembly コードを実行すること、および (b) WebAssembly にコンパイルされる言語を使用して言語サーバーを作成することです。

このブログ記事の例を実行するには、次のツールが必要です。VS Code、Node.js、Rust コンパイラツールチェーン、wasm-tools、および wit-bindgen。

ワーカーでの WebAssembly コードの実行

前回のブログ記事の例では、VS Code 拡張機能ホストのメインスレッドで WebAssembly コードを実行しました。これは、実行時間が短い限り問題ありません。ただし、長時間実行される操作は、拡張機能ホストのメインスレッドが他の拡張機能で使用できるように、ワーカーで実行する必要があります。

VS Code コンポーネントモデルは、ワーカー側と拡張機能メイン側の両方で必要なグルーコードを自動的に生成できるようにすることで、これを容易にするメタモデルを提供します。

次のコードスニペットは、ワーカーに必要なコードを示しています。この例では、コードが worker.ts という名前のファイルに保存されていることを前提としています。

import { Connection, RAL } from '@vscode/wasm-component-model';
import { calculator } from './calculator';

async function main(): Promise<void> {
  const connection = await Connection.createWorker(calculator._);
  connection.listen();
}

main().catch(RAL().console.error);

このコードは、拡張機能ホストのメインワーカーと通信するための接続を作成し、wit2ts ツールによって生成された calculator world で接続を初期化します。

拡張機能側では、WebAssembly モジュールをロードし、それを calculator world にもバインドします。計算を実行するための対応する呼び出しは、ワーカーで非同期的に実行されるため、待機する必要があります (たとえば、await api.calc(...))。

// The channel for printing the result.
const channel = vscode.window.createOutputChannel('Calculator');
context.subscriptions.push(channel);

// The channel for printing the log.
const log = vscode.window.createOutputChannel('Calculator - Log', { log: true });
context.subscriptions.push(log);

// The implementation of the log function that is called from WASM
const service: calculator.Imports.Promisified = {
  log: async (msg: string): Promise<void> => {
    // Wait 100ms to slow things down :-)
    await new Promise(resolve => setTimeout(resolve, 100));
    log.info(msg);
  }
};

// Load the WASM model
const filename = vscode.Uri.joinPath(
  context.extensionUri,
  'target',
  'wasm32-unknown-unknown',
  'debug',
  'calculator.wasm'
);
const bits = await vscode.workspace.fs.readFile(filename);
const module = await WebAssembly.compile(bits);

// Create the worker
const worker = new Worker(
  vscode.Uri.joinPath(context.extensionUri, './out/worker.js').fsPath
);
// Bind the world to the worker
const api = await calculator._.bind(service, module, worker);

vscode.commands.registerCommand(
  'vscode-samples.wasm-component-model-async.run',
  async () => {
    channel.show();
    channel.appendLine('Running calculator example');
    const add = Types.Operation.Add({ left: 1, right: 2 });
    channel.appendLine(`Add ${await api.calc(add)}`);
    const sub = Types.Operation.Sub({ left: 10, right: 8 });
    channel.appendLine(`Sub ${await api.calc(sub)}`);
    const mul = Types.Operation.Mul({ left: 3, right: 7 });
    channel.appendLine(`Mul ${await api.calc(mul)}`);
    const div = Types.Operation.Div({ left: 10, right: 2 });
    channel.appendLine(`Div ${await api.calc(div)}`);
  }
);

注意すべき重要な点がいくつかあります。

  • この例で使用されている WIT ファイルは、前回のブログ記事の計算機の例で使用されているものと違いはありません。
  • WebAssembly コードの実行はワーカーで行われるため、インポートされたサービス (上記の log 関数など) の実装は Promise を返すことができますが、必須ではありません。
  • WebAssembly は現在、同期実行モデルのみをサポートしています。その結果、ワーカーから WebAssembly コードを実行して、インポートされたサービスを呼び出すために拡張機能ホストのメインスレッドに呼び出すすべての呼び出しには、次のステップが必要です。
    1. 呼び出すサービス (たとえば、log 関数を呼び出す) を記述するメッセージを拡張機能ホストのメインスレッドにポストします。
    2. Atomics.wait を使用してワーカーの実行を一時停止します。
    3. 拡張機能ホストのメインスレッドでメッセージを処理します。
    4. Atomics.notify を使用してワーカーを再開し、結果を通知します。

この同期は、測定可能な時間のオーバーヘッドを追加します。これらのステップはすべてコンポーネントモデルによって透過的に処理されますが、開発者はそれらを認識し、インポートされた API サーフェスを設計する際にこれを考慮する必要があります。

この例の完全なソースコードは、VS Code 拡張機能サンプルリポジトリにあります。

WebAssembly ベースの言語サーバー

VS Code for the Web の WebAssembly サポートに取り組み始めたとき、私たちの想定されるユースケースの 1 つは、WebAssembly を使用して言語サーバーを実行することでした。VS Code の LSP ライブラリへの最新の変更と、WebAssembly と LSP をブリッジする新しいモジュールの導入により、WebAssembly 言語サーバーの実装は、オペレーティングシステムプロセスとして実装するのと同じくらい簡単になりました。

さらに、WebAssembly 言語サーバーは WebAssembly Core Extension 上で実行され、WASI Preview 1 を完全にサポートしています。これは、ファイルが GitHub リポジトリなどのリモートに保存されている場合でも、言語サーバーがプログラミング言語の通常のファイルシステム API を使用してワークスペース内のファイルにアクセスできることを意味します。

次のコードスニペットは、lsp_server クレートのサンプルサーバーに基づく Rust 言語サーバーを示しています。この言語サーバーは、言語分析を実行しませんが、GotoDefinition リクエストに対して定義済みの結果を返すだけです。

match cast::<GotoDefinition>(req) {
    Ok((id, params)) => {
        let uri = params.text_document_position_params.text_document.uri;
        eprintln!("Received gotoDefinition request #{} {}", id, uri.to_string());
        let loc = Location::new(
            uri,
            lsp_types::Range::new(lsp_types::Position::new(0, 0), lsp_types::Position::new(0, 0))
        );
        let mut vec = Vec::new();
        vec.push(loc);
        let result = Some(GotoDefinitionResponse::Array(vec));
        let result = serde_json::to_value(&result).unwrap();
        let resp = Response { id, result: Some(result), error: None };
        connection.sender.send(Message::Response(resp))?;
        continue;
    }
    Err(err @ ExtractError::JsonError { .. }) => panic!("{err:?}"),
    Err(ExtractError::MethodMismatch(req)) => req,
};

言語サーバーの完全なソースコードは、VS Code サンプルリポジトリにあります。

新しい @vscode/wasm-wasi-lsp npm モジュールを使用して、拡張機能の TypeScript コード内に WebAssembly 言語サーバーを作成できます。WebAssembly Core Extension を使用して WASI サポート付きのワーカーとして WebAssembly コードをインスタンス化します。これについては、Web 用 VS Code で WebAssembly を実行するブログ記事で詳しく説明しています。

拡張機能の TypeScript コードも簡単です。プレーンテキストファイル用のサーバーを登録します。

import {
  createStdioOptions,
  createUriConverters,
  startServer
} from '@vscode/wasm-wasi-lsp';

export async function activate(context: ExtensionContext) {
  const wasm: Wasm = await Wasm.load();

  const channel = window.createOutputChannel('LSP WASM Server');
  // The server options to run the WebAssembly language server.
  const serverOptions: ServerOptions = async () => {
    const options: ProcessOptions = {
      stdio: createStdioOptions(),
      mountPoints: [{ kind: 'workspaceFolder' }]
    };

    // Load the WebAssembly code
    const filename = Uri.joinPath(
      context.extensionUri,
      'server',
      'target',
      'wasm32-wasip1-threads',
      'release',
      'server.wasm'
    );
    const bits = await workspace.fs.readFile(filename);
    const module = await WebAssembly.compile(bits);

    // Create the wasm worker that runs the LSP server
    const process = await wasm.createProcess(
      'lsp-server',
      module,
      { initial: 160, maximum: 160, shared: true },
      options
    );

    // Hook stderr to the output channel
    const decoder = new TextDecoder('utf-8');
    process.stderr!.onData(data => {
      channel.append(decoder.decode(data));
    });

    return startServer(process);
  };

  const clientOptions: LanguageClientOptions = {
    documentSelector: [{ language: 'plaintext' }],
    outputChannel: channel,
    uriConverters: createUriConverters()
  };

  let client = new LanguageClient('lspClient', 'LSP Client', serverOptions, clientOptions);
  await client.start();
}

コードを実行すると、プレーンテキストファイルのコンテキストメニューに Goto Definition エントリが追加されます。このアクションを実行すると、対応するリクエストが LSP サーバーに送信されます。

Running the goto definition action

@vscode/wasm-wasi-lsp npm モジュールは、ドキュメント URI をワークスペース値から WASI Preview 1 ホストで認識される値に自動的に変換することに注意してください。上記の例では、VS Code 内のテキストドキュメントの URI は通常、vscode-vfs://github/dbaeumer/plaintext-sample/lorem.txt のようになります。この値は、WASI ホスト内で認識される file:///workspace/lorem.txt に変換されます。この変換は、言語サーバーが URI を VS Code に送り返すときにも自動的に行われます。

ほとんどの言語サーバーライブラリはカスタムメッセージをサポートしているため、Language Server Protocol Specification にまだ存在しない機能を言語サーバーに簡単に追加できます。次のコードスニペットは、以前に使用した Rust 言語サーバーに、指定されたワークスペースフォルダー内のファイルをカウントするためのカスタムメッセージハンドラーを追加する方法を示しています。

#[derive(Debug, Eq, PartialEq, Clone, Deserialize, Serialize)]
#[serde(rename_all = "camelCase")]
pub struct CountFilesParams {
    pub folder: Url,
}

pub enum CountFilesRequest {}
impl Request for CountFilesRequest {
    type Params = CountFilesParams;
    type Result = u32;
    const METHOD: &'static str = "wasm-language-server/countFilesInDirectory";
}

//...

for msg in &connection.receiver {
    match msg {
		//....
		match cast::<CountFilesRequest>(req) {
    		Ok((id, params)) => {
				eprintln!("Received countFiles request #{} {}", id, params.folder);
        		let result = count_files_in_directory(&params.folder.path());
        		let json = serde_json::to_value(&result).unwrap();
        		let resp = Response { id, result: Some(json), error: None };
        		connection.sender.send(Message::Response(resp))?;
        		continue;
    		}
    		Err(err @ ExtractError::JsonError { .. }) => panic!("{err:?}"),
    		Err(ExtractError::MethodMismatch(req)) => req,
		}
	}
	//...
}

fn count_files_in_directory(path: &str) -> usize {
    WalkDir::new(path)
        .into_iter()
        .filter_map(Result::ok)
        .filter(|entry| entry.file_type().is_file())
        .count()
}

LSP サーバーにこのカスタムリクエストを送信する TypeScript コードは次のようになります。

const folder = workspace.workspaceFolders![0].uri;
const result = await client.sendRequest(CountFilesRequest, {
  folder: client.code2ProtocolConverter.asUri(folder)
});
window.showInformationMessage(`The workspace contains ${result} files.`);

これを vscode-languageserver リポジトリで実行すると、次の通知が表示されます。

Running count all files

言語サーバーは、Language Server Protocol 仕様で指定されている機能を必ずしも実装する必要はないことに注意してください。拡張機能が WASI Preview 1 ターゲットにのみコンパイルできるライブラリコードを統合したい場合、VS Code がコンポーネントモデルの実装で WASI 0.2 プレビューをサポートするまで、カスタムメッセージを備えた言語サーバーを実装することが適切な選択肢となる可能性があります。

今後の展望

前回のブログ記事で述べたように、VS Code 用の WASI 0.2 プレビューを実装する取り組みを継続しています。また、WASM にコンパイルされる Rust 以外の言語を含むようにコード例を広げる予定です。

ありがとうございます。

Dirk と VS Code チーム

ハッピーコーディング!