Test case: var s1 = "\nAbc\n"; var s2 = s1.replace(/(\n)[^\n]+$/, '$1'); if (s1 == s2) alert("expected: s1 == s2"); else alert('s1 != s2: "' + s2.replace(/\n/g,"\\n") + '" != "\\nAbc\\n"'); In FireFox, IE and Perl, s1 == s2. In Safari (even in the latest nightly builds), s2 is stripped of the inner 'Abc' characters. Changing the regex to use * instead of + doesn't change the result either.
Created attachment 17031 [details] Test case from Comment #0
What's broken here is the $ operator. It's matching a newline at the end of the string. I have a fix.
Created attachment 17216 [details] patch for this and a few other problems
Comment on attachment 17216 [details] patch for this and a few other problems r=me
Committed revision 27752.
I take it this was no change for sunspider?
(In reply to comment #6) > I take it this was no change for sunspider? I'm not sure. I'll test now.
SunSpider claims this slowed things down almost 1%. But what is so crazy is that the effects were mostly on the tests that don't use regular expressions at all! For example, it says partial-sums is 2% slower. But there's not a single call into the regular expression for partial-sums. Similarly, it claims that string-base64 is 2% slower. Also doesn't use regular expressions at all. Claims that string-fasta is 2.6% slower. Also doesn't use regular expressions at all. It says regexp-dna is 0.6% faster. That one uses regular expressions. This patch is entirely about correctness, not performance, and it should make regular expressions slightly *faster*. I have no idea why SunSpider thinks it makes non-regular-expression tests slower. We may need to fix SunSpider.