Bug: Bad behaviour with combination of: StringScanner#scan, multiline regexp, multiple lines

[hmdne]

Describe the bug

When giving StringScanner#scan a multiline (//m) regexp, instead of scanning just the next character, it scans characters after a newline too.

In Ruby, multiline modifier changes semantics of . to mean "any character", not "any character except \n".

In JavaScript instead, it changes semantics of ^ and $ to how they work in Ruby even without //m, so they match beginning/ending either of string or line. Except... there's no \A or \z.

Opal's StringScanner#scan implementation adds ^ to the beginning of the supplied regexp and copies the flags.

All combined cause a hard-to-discover bug. I don't have simple solutions for that issue, maybe except of using lookbehind to simulate \A in Opal's clone of StringScanner, but that only recently has been implemented in Safari.

Opal version: master

To Reproduce

[user@localhost mnt]# opal -rstrscan -e 'StringScanner.new("hello\nhello").tap { |i| p 10.times.map { i.scan(/h/m) } }'
["h", "h", "h", "h", "h", "h", "h", nil, nil, nil]
[user@localhost mnt]# ruby -rstrscan -e 'StringScanner.new("hello\nhello").tap { |i| p 10.times.map { i.scan(/h/m) } }'
["h", nil, nil, nil, nil, nil, nil, nil, nil, nil]
[user@localhost mnt]# 

[takaram]

The root cause seems to be confusing m flag of Ruby and JavaScript.

Actually m flag of Ruby only changes the semantics of . and does not change ^ or $.
Equivalent flag in JavaScript is s.

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Regular_expressions#advanced_searching_with_flags

[hmdne]

Yes @takaram, I was also mistaken about this in the first version of the post. Later I edited it to clarify. But I wasn't aware of the JS s flag. #2610 fixes this issue by transpiling the regexps (but still needs some work due to performance impact). As of now, . is transpiled to [\s\S] if m flag is present. I foresee an issue with things like Regexp.union if we chose to depend on the flags.