I am implementing new parsers for gcc errors (see http://issues.jenkins-ci.org/browse/JENKINS-4753), but I stumbled upon a problem to make unit tests succeed.
The ParserTester base class is checking for each parser that the test input is not matched by any other parser.
As I am implementing a parser improving message matching reliability for gcc4 output, I left the legacy parser that also handles message of previous versions of gcc. Obviously, no one will ever have to use both parsers in the same build, so it doesn't matter the 2 parser can match part of the test input of the other. Moreover my parser matches part of the output of some other compilers (msbuild, javac).

Fondamentaly I don't think such a restriction should be imposed on parsers. As the number of parsers will grow, we will inevitably have collisions between parsers. The more variable an input is, the more chances you have that the output of another tool could match its 'grammar'. It doesn't mean a bug. It's just you cannot use these tools together in the same build.

If we really want to keep having a strong checking against interactions between tools, maybe we should provide a way to declare pairs of incompatible parsers, and do not check these combinations.
Otherwise, I wonder if there would be a better way to discriminate the output of the tools.