Checkstyle SyntaxChecker reports incorrect Severity Level

[rustushki]

My checkstyle configuration contains the following module:
...
<module name="TodoComment">
<property name="severity" value="info"/>
<message key="todo.match" value="Comment matches TODO pattern."/>
</module>
...

Notice that the severity value is set to 'info'. However, when I leave a TODO comment in my code, the message in my loc_list shows up as error. Example:

/path/to/myJavaclass.java|49 error| Comment matches TODO pattern

Also, thank you for adding Checkstyle support in syntastic. It's been invaluable to me.

[lcd047]

Yes, the checkstyle checker doesn't try to distinguish between message priorities, so basically everything is an error. :) As far as I can tell changing that would involve parsing XML in Vim, which would be a major pain. @troydm any comments?

[troydm]

hmm... unless checkstyle can't distinguish message priorities there is only one ugly hack way to fix this problem, e.g. do an xml configuration parse and then parse each message according to it's priority but that's just an overkill as i see it. am i wrong?

[lcd047]

Checkstyle does distinguish between message priorities when the output format is set to XML (option -f xml). It's still XML, but simpler than the config files. We'd have to parse messages like this:

<error line="651" severity="error" message="First sentence should end with a period." source="com.puppycrawl.tools.checkstyle.checks.javadoc.JavadocStyleCheck"/>

On a second thought, that isn't that bad. Basically, we'd have to decode XML entities, plus maybe the character references.

[lcd047]

Ok, a checker based on checkstyle with XML output looks like this: 6cc0ed4. It recognizes messages with priorities error and warning, the rest are ignored (priority names are defined by user, in the config file).

However, there is a deal breaker for it: since we can't decode XML entities before %f is parsed as an errorformat, files with names containing one of the characters <, >, ', ", or & can't be parsed. Boo.

[troydm]

Nice change! However that deal breaker imposes some significant limitations on file names :( i'm not sure how to deal with this without making some changes to how syntastic parses errorformat :(

[lcd047]

Well, there are a number of ways to deal with it:

1. pipe the output of the checker to an external program (say awk), that would decode the filenames; this has the disadvantage that it makes the checker dependent on an external program;
2. override bufnr in the errors with bufnr(''); this has the disadvantage that it breaks reporting of errors in included files;
3. use the old checker if the filename contains one of the forbidden characters; this has the disadvantage that the errors detected by syntastic would depend on the filename;
4. restore the old behaviour, and document that all messages are recognized as errors.

I'm inclined to choose 4.

[lcd047]

Ok, I added a note to the wiki, until we find a real solution. Sorry about that.

[lcd047]

It's now possible to decode XML entities in before parsing errors with errorformat. The solution above to turn on XML output is thus viable. See #753.