Based on that output (for which I had to get myself a copy of ecj
and man, that is some wacky output) a standard Build regex unfortunately is (probably) not going to do what you want.
There are two things here; file_regex
and line_regex
; you generally use either file_regex
alone, or line_regex
in combination with file_regex
:
-
file_regex
needs to match, in order, filename, line, column, message
-
line_regex
(if you use it) needs to match, in order, line, column, error; and then, after this matches, it goes backwards through the buffer to find the first line prior to the one that matched in order to pick up the filename from it
In both cases, match items can be missing, but the items that do exist need to be in that order.
The output for ECJ doesn’t match 1:1 with file_regex
because although it has the filename and line, it doesn’t have either a column or a message in it. So it can tell you where the error is located, but can’t tell you what the error was.
line_regex
can match on the line that has the error message, but the fact that it has no line and column information in it means that at best it can capture the error message but can’t tell you where the actual error happened.
Depending on your use case, this might not matter.
If you use a file_regex
like this:
"file_regex": "^\\d+\\. ERROR in (.*) \\(at line (\\d+)\\)",
It will find the errors and show them to you as annotations, but the lack of an error message capture means that the whole string becomes the error, so you end up with:
Alternately, if you add ()()
to the end of the regex (to make an empty capture on column and error message), you still get the annotation, but now it has no error message in it because it could not capture anything:

Either way, double clicking on errors in the build output will open the file to the offending line (or focus it, if it’s already the file you’re editing), and the commands for navigating through build errors will still land on it.
If it’s possible to somehow configure ecj
to generate a more friendly error output, that could work. The only other solution currently would be to create some sort of script or program which can transform the compiler output into a format that works better, and slot that into the build.