[Webkit-unassigned] [Bug 104712] New: figure out how to trap new errors resulting from TestExpectation patches

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=104712

           Summary: figure out how to trap new errors resulting from
                    TestExpectation patches
           Product: WebKit
           Version: 528+ (Nightly build)
          Platform: Unspecified
        OS/Version: Unspecified
            Status: NEW
          Keywords: NRWT
          Severity: Normal
          Priority: P2
         Component: Tools / Tests
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: dpranke at chromium.org
                CC: eric at webkit.org, abarth at webkit.org, ojan at chromium.org,
                    rniwa at webkit.org


See bug 104687 and bug 60466 for some context ...

It's possible to change a line in a TestExpectations file that is perfectly legal on its own, but causes errors somewhere else (e.g., if you insert a line at the top duplicating a line at the bottom). The only way to catch this currently when running check-webkit-style is to lint the whole file and complain if there are any errors, but that has the downside that if the file is already broken for reasons unrelated to your patch, check-webkit-style will fail. We've now flipped back and forth on this twice (in the above bugs).

There are at least two ways to fix this "properly" ... the first, and probably more general, would be to run the style checker on the file both pre- and post- patch, and compare the output, and fail if the output introduces new errors (deleting old errors is probably okay). This might require a large amount of restructuring of the style checker, and figuring out if the output introduced new errors might be tricky (cf. the work we have to do in the EWS).

The second would be to change the linter so that if there were errors resulting from the interaction between two different lines, *both* lines reported an error. This would probably be straightforward, but the trick would be to structure this in such a way so that reporting both errors wasn't overly verbose.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.