ruby-trunk-changes r62839 - r62857

今日は ISeq 関連の GC mark の変更/修正や、File.read, binread, write, binwrite などがコマンドとの pipe 通信を使えないようにする変更などがありました。

nobu: r62839 2018-03-19 21:40:34 +0900

r62838 で begin 節以外の rescue/ensure でインデントチェックをしないようにしていましたが、do ... end のルールの do トークンにも token_info_push() を呼び出すアクションを追加してチェックできるようにしています。これでついでに気がついたんですが、 brace_block というノードのルールに {} のブロックがあるのは当然として do...end の記法のブロックも存在してるんですよね。do_block というノードも別にあるんですけど。使われてる場所が微妙に違うのは優先順位の違いだと思うけど、そうだとすると brace_block に do...end のルールがあるのは変な気が。なんでだろ。

usa: r62840 2018-03-19 22:04:22 +0900

win32/README.win32 に Windows 環境での開発に必要なものとして patch コマンドを追記しています。またビルドの手順に nmake up の実行を追加しています。

nobu: r62841 2018-03-19 23:12:00 +0900

parse.y の yycompile() で rubyスクリプトファイル名を文字列オブジェクトから StringValueCStr() で取り出して NUL 文字終端させるようにしています。また template/prelude.c.tmpl でも ruby スクリプトを埋め込むための prelude_name_xxx の変数に NUL 文字を置くようにしています。

usa: r62843 2018-03-20 00:40:32 +0900

r62840 の再修正。 win32/README.win32 の nmake up の実行は svn リポジトリからチェックアウトしている時だけと書かれています。

svn: r62844 2018-03-20 00:40:33 +0900

version.h の日付更新。

tenderlove: r62851 2018-03-20 03:21:54 +0900

r62706 の ISeq の operand の GC mark 処理の再挑戦。 i686 環境での不具合修正と、バイナリフォーマットからのロード処理時の ISeq への ISEQ_MARKABLE_ISEQ のセットも追加しているそうです。 [ruby-core:84909] [Feature #14370]

nobu: r62856 2018-03-20 17:36:42 +0900

ISeq のバイナリフォーマットからのロード時に struct rb_iseq_constant_body::iseq_encoded を ibf_load_iseq_each() でセットしていたのを、ここから呼ぶ ibf_load_code() の中でセットするようにして、struct rb_iseq_constant_body::iseq_size もこの中で実際にデコードした命令数を逐次セットするようにしています。これは GC の mark 処理がこの iseq_size をみて iseq_encoded の配列の中身の mark する範囲を決めてるみたいなので、そのため後で全体のサイズを入れるのだと mark 漏れが起きる可能性があったようです。[追記]じゃなくて iseq_encoded が NULL の瞬間があってそれによって SEGV する可能性があったので先にセットしておくということだそうです。[/追記]

shugo: r62857 2018-03-20 18:09:49 +0900

File.read, File.binread, File.write, File.binwrite メソッドでは IO.read などのコマンド実行と pipe で読み書きすることができる機能を無効にするようにしています。 File クラスの特異メソッドを使うと安全にファイルパスを引数として渡せるようにするためのものだと思います。 File クラスでメソッドを再定義しているわけではなくて、むしろ receiver が IO クラスでなかったら pipe 使えないようにするという感じになってます。つまり Socket.read とかも pipe 機能は無効になってると思います。 [ruby-core:84495] [Feature #14245]