Fixes the second of the two assertion failures here:
TestRubyOptions#test_shebang [/Users/alex/src/github.com/Ruby/ruby/test/ruby/test_rubyoptions.rb:514]:
pid 49518 exit 0.
1. [1/2] Assertion for "stdout"
| <["\"あ\""]> expected but was
| <["\"\\u3042\""]>.
2. [2/2] Assertion for "stderr"
| Expected /shebang line ending with \\r/ to match "".
Finished tests in 0.030572s, 32.7097 tests/s, 359.8064 assertions/s.
1 tests, 11 assertions, 1 failures, 0 errors, 0 skips
ruby -v: ruby 3.4.0dev (2024-08-22T14:01:55Z master 56a34b5af5) +PRISM [arm64-darwin23]
make: *** [yes-test-all] Error 1
Root cause
The "string" (pointer+length combo) given to pm_parser_warn_shebang_carriage_return ended on the \r, right before the \n. So the check for \r\n actually found 8\r instead.
Solution approach
When there is a newline, bump the length by 1 to include it as part of the string passed to pm_parser_warn_shebang_carriage_return, which can then accurately detect the \r\n.
Just to confirm: the last "valid" index of this slice is at [length - 1], and [length] is one past the end (at least the part of it that we're guaranteed to exist), right?
Related to #2996
Fixes the second of the two assertion failures here:
Root cause
The "string" (pointer+length combo) given to
pm_parser_warn_shebang_carriage_return
ended on the\r
, right before the\n
. So the check for\r\n
actually found8\r
instead.Solution approach
When there is a newline, bump the
length
by 1 to include it as part of the string passed topm_parser_warn_shebang_carriage_return
, which can then accurately detect the\r\n
.