こんにちは、ruby-devチームの遠藤（@mametter）です。 Among Usというゲームをやってるのですが、友達が少なくてあまり開催できないのが悩みです。
今日は、Ruby 3.1に導入される予定のerror_highlightという機能を紹介します。
どんな機能？
NoMethodErrorが起きたとき、次のような表示が出るようになります。
どこのメソッド呼び出しで失敗したかが一目瞭然ですね。これだけの機能ですが、使ってみると意外と便利です。
もう少し詳しく
この機能が本領を発揮するのは、RailsのparamsやJSONデータの取り扱いなどのときです。
たとえばjson[:articles][:title]みたいなコードを書いて、undefined method '[]' for nil:NilClassという例外が出たとします。
このとき、変数jsonがnilだったのか、json[:articles]の返り値がnilだったのかは、残念ながらコードだけ見ても判断できません。
特定するには、デバッグ出力を挟んで再実行する必要がありました。
error_highlightがあると、これがひと目で判別できます。
$ ruby test.rb
test.rb:2:in `<main>': undefined method `[]' for nil:NilClass (NoMethodError)
title = json[:articles][:title]
^^^^^^^^^^^↑は、jsonがnilだったケースです。
$ ruby test.rb
test.rb:2:in `<main>': undefined method `[]' for nil:NilClass (NoMethodError)
title = json[:articles][:title]
^^^^^^^^↑は、json[:articles]がnilを返したことがわかります。
実装について
error_highlightはRubyインタプリタの実装に深く関わってます。ざっくりイメージで紹介します。
Rubyは、プログラムを抽象構文木に変換し、それをバイトコードにコンパイルした上で実行しています。
たとえば json[:articles][:title]というコードは、次のような抽象構文木（イメージ）に変換されます。
それぞれの四角は抽象構文木のノードを表します。ノードは、メソッド名などの付加情報や、レシーバや引数などの子ノードへの参照を持ちます。それに加え、ノードは"ID"と"column"という情報を持っています。"ID"はノードを一意に特定する番号です。"column"は、そのノードに対応するコードの範囲を表しています*1。
それから、この抽象構文木をおおよそ次のようなバイトコード（イメージ）にコンパイルします。RubyのVMはスタックマシンで、まあなんとなく読めるかと思います*2。
1: getlocal :json # ID: 3 2: putobject :articles # ID: 4 3: send :[] # ID: 2 4: putobject :title # ID: 5 5: send :[] # ID: 1
このとき、各命令が由来となったノードのIDを持っているのがRuby 3.1で新たに実装したところで、error_highlightの肝になります。
json[:articles]がnilを返し、nilに対して[]メソッドを呼んでしまった場合、5番目のsend命令が失敗します。このとき、5番目の命令は"ID: 1"という参照を持っているので、どのノードで実行失敗したのかがわかります。そして、抽象構文木のノードには"column"情報があるので、コード中のどの範囲でエラーが起きたかという情報を得ることができます。
ID 1のノードのcolumnは 0...23 となっていて、これは json[:articles][:title]という文字列全体の範囲に対応しています。この全体に下線を引くとどこでエラーが起きたかわかりにくいので、error_highlightはなるべくメソッド名の位置を特定して線を引くようにしています。大まかに言えば、レシーバの子ノードである ID 2のノードの終端より後、つまり [:title]の下にだけ下線を引くようになっています。
クレジットと裏話
ノードにカラム情報をもたせるようにしたのはyui-knkさんです（RubyKaigi 2018の発表）。 error_highlightの原型もyui-knkさんが作っていたのですが、放置状態になっていたので、今回遠藤が引き取って完成させました。
なぜ引き取ったかと言うと、RubyKaigi Takeout 2021で遠藤が発表したTypeProf for IDEの実装のために必要だったからです。 IDEではエラー箇所をカラム単位で下線を引いて示すのが普通なので、ほぼ同じ機構が必要でした。 そのために必要な拡張を実装すると、そのおまけとしてerror_highlightが実現可能になりました。
命令ごとに由来となったノードIDを記録するためには、多少メモリを消費してしまいます*3*4。 ここは、開発体験向上とのトレードオフでした。 各命令にノードIDではなくカラム位置自体をもたせてしまう方法もあるのですが、よりメモリ消費量が大きくなるので、抽象構文木を経由して位置を特定する現在の方法になりました。
なお、抽象構文木自体はメモリに保存されておらず、必要になった時（つまりエラーが発生したとき）に、ファイルにあるソースコードを再度読み込んでパースし直しています。
このアプローチでは、ソースファイルが書き換えられた場合などはノードを正しく同定できなくなる可能性があります。
また、evalで実行されているソースコードについてはerror_highlightは動きません（このため、現在のところirbでは動きません）。
現在のところ隠しコマンドですが、RubyVM.keep_script_lines = trueとすると、インタプリタがソースコードを保持し続けるようになり、ソースコードの再読み込みは行われなくなり、evalについてもerror_highlightが動くようになります。
まとめ
Ruby 3.1では、NoMethodErrorのエラー表示がちょっと親切になります。 ささやかな改良なので過剰に期待されると困りますが、「Ruby 3.1.0-preview1を実際に使ってみたら予想外に開発体験がよくなった」という声をちらほら頂いているので、ほどほどにご期待ください。