RESOLVED WONTFIX 79703
[chromium] Fix fast/regex/overflow.html after r108999 
https://bugs.webkit.org/show_bug.cgi?id=79703
Summary [chromium] Fix fast/regex/overflow.html after r108999
Adrienne Walker
Reported 2012-02-27 14:16:07 PST
http://trac.webkit.org/changeset/108999 started throwing a SyntaxError exception in Yarr parsing, but Chromium doesn't behave similarly. See: http://test-results.appspot.com/dashboards/flakiness_dashboard.html#tests=fast%2Fregex%2Foverflow.html&showExpectations=true
Attachments
Add attachment proposed patch, testcase, etc.
Michael Saboff
Comment 1 2012-02-27 15:56:53 PST
Probably make sense to check in platform specific results for the chromium failures.
Kentaro Hara
Comment 2 2012-02-27 17:18:09 PST
(In reply to comment #1) > Probably make sense to check in platform specific results for the chromium failures. I am not sure if the rebaselining is a correct fix. Generally speaking, 4294967295 < UINT_MAX. Why do you think that we should throw "number too large in {} quantifier" exception for 4294967295? Would you please add me to bug 70648? (The bug says "You are not authorized to access bug #70648.":-)
Michael Saboff
Comment 3 2012-02-27 17:51:10 PST
(In reply to comment #2) > (In reply to comment #1) > > Probably make sense to check in platform specific results for the chromium failures. > > I am not sure if the rebaselining is a correct fix. Generally speaking, 4294967295 < UINT_MAX. Why do you think that we should throw "number too large in {} quantifier" exception for 4294967295? Given that string lengths are 0 to UINT_MAX-1 (4294967295) the value seems reasonable. This is only for the "min" value in a quantifier. > Would you please add me to bug 70648? (The bug says "You are not authorized to access bug #70648.":-) I added you as a cc to https://bugs.webkit.org/show_bug.cgi?id=70648.
Kentaro Hara
Comment 4 2012-02-27 18:45:29 PST
(In reply to comment #3) > Given that string lengths are 0 to UINT_MAX-1 (4294967295) the value seems reasonable. This is only for the "min" value in a quantifier. Thank you very much for the clarification. (In reply to comment #1) > Probably make sense to check in platform specific results for the chromium failures. As you pointed out, the rebaselining would make sense.
Adrienne Walker
Comment 5 2012-02-28 09:23:01 PST
(In reply to comment #4) > (In reply to comment #3) > > Given that string lengths are 0 to UINT_MAX-1 (4294967295) the value seems reasonable. This is only for the "min" value in a quantifier. > > Thank you very much for the clarification. > > (In reply to comment #1) > > Probably make sense to check in platform specific results for the chromium failures. > > As you pointed out, the rebaselining would make sense. I find it very strange to rebaseline a test to include a FAIL line. If this test behavior is not supposed to be cross-port, maybe it should go into LayoutTests/platform/mac.
Michael Saboff
Comment 6 2012-02-28 10:03:05 PST
(In reply to comment #5) > (In reply to comment #4) > > (In reply to comment #3) > > > Given that string lengths are 0 to UINT_MAX-1 (4294967295) the value seems reasonable. This is only for the "min" value in a quantifier. > > > > Thank you very much for the clarification. > > > > (In reply to comment #1) > > > Probably make sense to check in platform specific results for the chromium failures. > > > > As you pointed out, the rebaselining would make sense. > > I find it very strange to rebaseline a test to include a FAIL line. > > If this test behavior is not supposed to be cross-port, maybe it should go into LayoutTests/platform/mac. Actually the behavior is cross port for all ports using Yarr. Correct me if I'm wrong, but I think that is most ports.
Kentaro Hara
Comment 7 2012-02-28 15:33:07 PST
(In reply to comment #5) > > As you pointed out, the rebaselining would make sense. > > I find it very strange to rebaseline a test to include a FAIL line. > > If this test behavior is not supposed to be cross-port, maybe it should go into LayoutTests/platform/mac. Yes. By "rebaseline", I meant, we should put the Chromium result to LayoutTests/platform/chromium/fast/regex/overflow-expected.txt. Then, mac/gtk/qt/... will lookup LayoutTests/fast/regex/overflow-expected.txt and Chromium will lookup LayoutTests/platform/chromium/fast/regex/overflow-expected.txt.
Adrienne Walker
Comment 8 2012-02-29 10:10:09 PST
(In reply to comment #7) > (In reply to comment #5) > > > As you pointed out, the rebaselining would make sense. > > > > I find it very strange to rebaseline a test to include a FAIL line. > > > > If this test behavior is not supposed to be cross-port, maybe it should go into LayoutTests/platform/mac. > > Yes. By "rebaseline", I meant, we should put the Chromium result to LayoutTests/platform/chromium/fast/regex/overflow-expected.txt. Then, mac/gtk/qt/... will lookup LayoutTests/fast/regex/overflow-expected.txt and Chromium will lookup LayoutTests/platform/chromium/fast/regex/overflow-expected.txt. I think I understand what you're saying. I just find it strange to check in a Chromium-specific baseline into LayoutTests/platform/chromium/fast/regex/overflow-expected.txt that includes a FAIL line. There's a difference between a port-specific expectation of "this test passes, but has slightly different pixels or text" and "this test says it fails".
Kentaro Hara
Comment 9 2012-02-29 16:05:29 PST
(In reply to comment #8) > I just find it strange to check in a Chromium-specific baseline into LayoutTests/platform/chromium/fast/regex/overflow-expected.txt that includes a FAIL line. There's a difference between a port-specific expectation of "this test passes, but has slightly different pixels or text" and "this test says it fails". Yes. The FAIL line means that "This test fails. Please ignore the failure." On the other hand, rebaselining means that we need to add port-specific results to LayoutTests/platform/*. In your case, you need to remove the FAIL line and add the chromium-specific results to LayoutTests/platform/chromium/*.
Note You need to log in before you can comment on or make changes to this bug.