Bug 104712

Summary: figure out how to trap new errors resulting from TestExpectation patches
Product: WebKit Reporter: Dirk Pranke <dpranke>
Component: Tools / TestsAssignee: Nobody <webkit-unassigned>
Status: NEW ---    
Severity: Normal CC: abarth, eric, rniwa
Priority: P2 Keywords: NRWT
Version: 528+ (Nightly build)   
Hardware: Unspecified   
OS: Unspecified   

Description Dirk Pranke 2012-12-11 13:39:57 PST
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.