This patch suggests relocating the code dealing with `SCRIPT_LINES__` from ast.c to ruby_parser.c.
## Background
- I guess `AbstractSyntaxTree.of` method used to use `SCRIPT_LINES__` internally for some reason before
- However, now it appears `SCRIPT_LINES__` is no longer used meaningfully by the method
- As evidence of this, (and as my patch shows,) removing the function call of `rb_script_lines_for()` from `ast_s_of()` does not affect the result of `test/ruby/test_ast.rb`
Given the above, I think two possibilities can be considered:
- (A) `AbstractSyntaxTree.of` has not needed `SCRIPT_LINES__` already (I pick this)
- (B) We lack a test case of `AbstractSyntaxTree.of` that needs to use `SCRIPT_LINES__`
## Besides,
The current implementation causes strange behavior:
```console
ruby -e"SCRIPT_LINES__ = {__FILE__ => []}; puts RubyVM::AbstractSyntaxTree.of(->{ 1 + 2 }, keep_script_lines: true).script_lines"
=> `-e:1:in '<main>': undefined method 'script_lines' for nil (NoMethodError)`
```
I think this is a bug because `AbstractSyntaxTree.of` is not supposed to return `nil` even in this case.
This happens due to the ast.c's dependence on `SCRIPT_LINES__`.
And at the end of the `ast_s_of()`, `node_find()` can not find the target child node obviously because it doesn't make sense to look for a corresponding node made from the parameter of `AbstractSyntaxTree.of` in the AST tree made from the value of `{__FILE__ => []}`
## Solution
Since I think it's good enough `SCRIPT_LINES__` to be only referred by ruby.c, I chose the possibility "(A)" and wrote this patch which moves `rb_script_lines_for()` from ast.c to ruby_parser.c.
So as the result:
- `ast_s_of()` function no longer look up `SCRIPT_LINES__`
- Even so, this patched code passes the existing tests
- The strange behavior above no longer happens (I also added a test for it)
Please correct me if I miss something🙏
This patch surppresses the warning below:
```console
compile.c:10314:1: warning: control reaches end of non-void function [-Wreturn-type]
10314 | }
| ^
```
Launchable reported that this was the most "flaky" test. Perhaps the
default timeout (10 seconds) is too tight for a test that uses
`GC.stress = true`. I try to relax the limit.
On Linux, `siginfo_t` uses a union for each `si_code`, and the field
corresponding to `si_pid` does not belong to the `_sigfault` field for
SIGSEGV. It actually overlaps the `si_addr` field, which is usually
non-zero on stack overflow.
https://github.com/ruby/ruby/pull/10201#issuecomment-2034723244
HASUMI Hitoshi
Hiroshi SHIBATA
tomoya ishida
Yusuke Endoh
yui-knk
git
Kevin Newton
Maxime Chevalier-Boisvert
Takashi Kokubun
Nobuyoshi Nakada