@andy-twosticks Nice find! This would point to a difference in how the parser constructs Regex versus how the constructor forms construct Regex.

@enebo Any idea why this might be? Something odd with the escaping?

@headius My only guess would be that bytelist after parsing does not remove the \ and it does it in the constructor of the regexp. That would make the bytelists different perhaps?

It looks like the sources are difference in these two cases.

[] ~/projects/jruby $ jruby -e 'p /foo\/bar/.source'
"foo\\/bar"

[] ~/projects/jruby $ jruby -e 'p %r[foo/bar].source'
"foo/bar"

Ok, so stepping through the parser showed me that it's constructing the // form using foo\/bar in a ByteList and the %r[] form using foo/bar. Both proceed along the same path from there, and the compiled Regexps that result are the same. Only the sources differ.

Seems like either the one needs to be escaped or the other needs to be unescaped before constructing the Regexp.

Ruby 2.3 for comparison:

[] ~/projects/jruby $ ruby23 -e 'p %r[foo/bar].source'
"foo/bar"

[] ~/projects/jruby $ ruby23 -e 'p /foo\/bar/.source'
"foo/bar"

A bit more comparison with MRI:

[] ~/projects/jruby $ ruby23 -rpp -rripper -e 'pp Ripper.tokenize("/foo\/bar/")'
["/", "foo", "/bar", "/"]

[] ~/projects/jruby $ ruby23 -rpp -rripper -e 'pp Ripper.tokenize("%r[foo/bar]")'
["%r[", "foo/bar", "]"]

We produce the same tokens, but when combining those string pieces we seem to be escaping the / again. Ripper isn't exactly the same as the normal parser, but it should be close.

So there was an extra append '' in our StringTerm code which MRI did not have nor did our ripper version of StringTerm. So pretty easy to delete that line. Spec added in commit b0abc53.