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

test/mozilla/mozilla.status

 # Copyright 2008 the V8 project authors. All rights reserved.
 # Redistribution and use in source and binary forms, with or without
 # modification, are permitted provided that the following conditions are
 # met:
 #
 #     * Redistributions of source code must retain the above copyright
 #       notice, this list of conditions and the following disclaimer.
 #     * Redistributions in binary form must reproduce the above
 #       copyright notice, this list of conditions and the following
 #       disclaimer in the documentation and/or other materials provided
@@ skipping 210 matching lines @@
 
 # Array.prototype.slice with zero arguments return undefined in JSC/V8, 
 # empty array in Spider/TraceMonkey.
 js1_5/Array/regress-451483: FAIL_OK
 
 
 #:=== RegExp:=== 
 # To be compatible with JSC we silently ignore flags that do not make
 # 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.
 ecma_3/RegExp/regress-330684: FAIL_OK
 
 
 # This test contains a regexp that runs exponentially long.  Spidermonkey
 # 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 {}
 # quantifiers.  Might fix by parsing numbers differently?
 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
 js1_2/regexp/beginLine: FAIL_OK
 js1_2/regexp/endLine: FAIL_OK
 
 
 # Date trouble?
 js1_5/Date/regress-301738-02: FAIL_OK
 
@@ skipping 170 matching lines @@
 ecma_2/RegExp/exec-001: FAIL_OK
 ecma_2/String/replace-001: FAIL_OK
 
 
 # We do not strip unicode format control characters. This is really
 # required for working with non-latin character sets.  We match JSC
 # and IE here.  Firefox matches the spec (section 7.1).
 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
 
 
 # The concat() method is defined in Array.prototype; not Array.
 js1_5/Array/regress-313153: FAIL_OK
 
 
 # Properties stack, fileName, and lineNumber of Error instances are
@@ skipping 25 matching lines @@
 # Unsupported list comprehensions: [ ... for ... ] and for each.
 js1_5/Regress/regress-352009: FAIL_OK
 js1_5/Regress/regress-349648: FAIL_OK
 
 
 # Expects top level arguments (passed on command line?) to be
 # the empty string?
 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
 # surrounding function, whereas Spidermonkey declares
 # them dynamically when the statement is executed.
 ecma_3/Function/scope-001: FAIL_OK
 ecma_3/FunExpr/fe-001: FAIL_OK
 js1_5/Scope/regress-184107: FAIL_OK
 
 
@@ skipping 274 matching lines @@
 ecma/Date/15.9.5.8: SKIP
 ecma/Date/15.9.5.9: SKIP
 ecma/Date/15.9.5.10-2: SKIP
 ecma/Date/15.9.5.11-2: SKIP
 ecma/Expressions/11.7.2: SKIP
 ecma/Expressions/11.10-2: SKIP
 ecma/Expressions/11.7.3: SKIP
 ecma/Expressions/11.10-3: SKIP
 ecma/Expressions/11.7.1: SKIP
 ecma_3/RegExp/regress-209067: SKIP