Add support for \b and ^ and $ in multiline mode, completing Irregexp...

test/mozilla/mozilla.status

Index: test/mozilla/mozilla.status
===================================================================
--- test/mozilla/mozilla.status	(revision 1094)
+++ test/mozilla/mozilla.status	(working copy)
@@ -229,24 +229,7 @@
 # sense.  This test expects us to throw exceptions.  
 ecma_3/RegExp/regress-57631: FAIL_OK
 

[Christian Plesner Hansen, 2009/01/19 10:28:59]

I wouldn't enable us by default yet, and so I wouldn't reenable these tests
either.

-# PCRE doesn't allow subpattern nesting deeper than 200, this tests
-# depth 500.  JSC detects the case, and return null from the match,
-# and passes this test (the test doesn't check for a correct return
-# value).
-ecma_3/RegExp/regress-119909: PASS || FAIL_OK
 
-
-# Difference in the way capturing subpatterns work.  In JS, when the
-# 'minimum repeat count' is reached, the empty string must not match.
-# In this case, we are similar but not identical to JSC.  Hard to
-# support the JS behavior with PCRE, so maybe emulate JSC?
-#
-# Note: We do not support toSource currently so we cannot run this
-# test. We should make an isolated test case for the regexp issue.
-ecma_3/RegExp/regress-209919: FAIL_OK
-js1_5/extensions/regress-459606: FAIL_OK
-
-
 # PCRE's match limit is reached.  SpiderMonkey hangs on the first one,
 # JSC returns true somehow.  Maybe they up the match limit?  There is
 # an open V8 bug 676063 about this.
@@ -257,7 +240,7 @@
 # standalone will hang, though apparently inside Firefox it will trigger a
 # long-running-script timeout.  JSCRE passes by hitting the matchLimit and
 # just pretending that an exhaustive search found no match.
-ecma_3/RegExp/regress-307456: PASS || FAIL_OK
+ecma_3/RegExp/regress-307456: FAIL_OK
 
 
 # We do not detect overflow in bounds for back references and {}
@@ -265,19 +248,6 @@
 js1_5/Regress/regress-230216-2: FAIL_OK
 
 
-# According to ECMA-262, \b is a 'word' boundary, where words are only
-# ASCII characters.  PCRE supports non-ASCII word characters.
-js1_5/Regress/regress-247179: FAIL_OK
-
-
-# Regexp too long for PCRE.
-js1_5/Regress/regress-280769: PASS || FAIL
-js1_5/Regress/regress-280769-1: PASS || FAIL
-js1_5/Regress/regress-280769-2: PASS || FAIL
-js1_5/Regress/regress-280769-4: PASS || FAIL
-js1_5/Regress/regress-280769-5: PASS || FAIL
-
-
 # We do not support static RegExp.multiline - should we?.
 js1_2/regexp/RegExp_multiline: FAIL_OK
 js1_2/regexp/RegExp_multiline_as_array: FAIL_OK
@@ -468,12 +438,6 @@
 ecma_3/Unicode/uc-001: FAIL_OK
 
 
-# A non-breaking space doesn't match \s in a regular expression.  This behaviour
-# matches JSC.  All the VMs have different behaviours in which characters match
-# \s so we do the same as JSC until they change.
-ecma_3/Unicode/uc-002: FAIL_OK
-
-
 # String.prototype.split on empty strings always returns an array
 # with one element (as specified in ECMA-262).
 js1_2/Array/array_split_1: FAIL_OK
@@ -519,18 +483,16 @@
 js1_5/Regress/regress-336100: FAIL_OK
 
 
-# Regular expression test failures due to PCRE. We match JSC (ie, perl)
-# behavior and not the ECMA spec.
-ecma_3/RegExp/15.10.2-1: FAIL_OK
-ecma_3/RegExp/perlstress-001: FAIL_OK
-ecma_3/RegExp/regress-334158: PASS || FAIL
-
-
 # This test requires a failure if we try to compile a function with more
 # than 65536 arguments.  This seems to be a Mozilla restriction.
 js1_5/Regress/regress-290575: FAIL_OK
 
 
+# This test fails due to http://code.google.com/p/v8/issues/detail?id=187
+# Failure to clear captures when a lookahead is unwound.
+ecma_3/RegExp/15.10.2-1: FAIL_OK
+
+
 # Fails because of the way function declarations are
 # handled in V8/JSC. V8 follows IE behavior and introduce
 # all nested function declarations when entering the