Chromium Code Reviews
chromiumcodereview-hr@appspot.gserviceaccount.com (chromiumcodereview-hr) | Please choose your nickname with Settings | Help | Chromium Project | Gerrit Changes | Sign out
(2232)

Unified Diff: test/mozilla/mozilla.status

Issue 18842: Experimental: periodic merge of the bleeding_edge branch to the... (Closed) Base URL: http://v8.googlecode.com/svn/branches/experimental/toiger/
Patch Set: Created 11 years, 11 months ago
Use n/p to move between diff chunks; N/P to move between comments. Draft comments are only viewable by you.
Jump to:
View side-by-side diff with in-line comments
Download patch
« no previous file with comments | « test/mjsunit/try_catch_scopes.js ('k') | tools/v8.xcodeproj/project.pbxproj » ('j') | no next file with comments »
Expand Comments ('e') | Collapse Comments ('c') | Show Comments Hide Comments ('s')
Index: test/mozilla/mozilla.status
===================================================================
--- test/mozilla/mozilla.status (revision 1168)
+++ test/mozilla/mozilla.status (working copy)
@@ -240,11 +240,8 @@
# '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,
@@ -265,11 +262,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
@@ -471,7 +463,7 @@
# 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
@@ -521,10 +513,12 @@
# 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.
« no previous file with comments | « test/mjsunit/try_catch_scopes.js ('k') | tools/v8.xcodeproj/project.pbxproj » ('j') | no next file with comments »

Powered by Google App Engine
This is Rietveld 408576698