Bug 104712 - figure out how to trap new errors resulting from TestExpectation patches
Summary: figure out how to trap new errors resulting from TestExpectation patches
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: Tools / Tests (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords: NRWT
Depends on:
Blocks:
 
Reported: 2012-12-11 13:39 PST by Dirk Pranke
Modified: 2017-07-18 08:27 PDT (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
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.