Experimental: periodic merge of the bleeding_edge branch to the...

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 222 matching lines @@
 # 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
+ecma_3/RegExp/regress-209919: PASS || FAIL_OK
+js1_5/extensions/regress-459606: PASS || 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
 
 
 # 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
@@ skipping 181 matching lines @@
 
 # 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
+ecma_3/Unicode/uc-002: PASS || 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
 
@@ skipping 29 matching lines @@
 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/perlstress-001: PASS || FAIL_OK
 ecma_3/RegExp/regress-334158: PASS || FAIL
 
+# 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: PASS || FAIL_OK
 
 # 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
 
 
 # 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
@@ skipping 280 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