error-prone icon indicating copy to clipboard operation
error-prone copied to clipboard

Compilation stopping at first error

Open sergiofigueras opened this issue 9 years ago • 8 comments

Hello guys,

I've developed a BugChecker here but when I compile it fails at the first error, but there are other instances of that error that I would like to show to the user.

I mean:

/Users/sergio/Documents/projects/utqg-errorprone/utqg-errorprone-sampleusage/src/test/java/com/utqg/errorprone/sample/HelloNotPassing1Test.java:10: error: [UTQG:HelperMethodCannotBePublic] Helper Methods of test classes cannot be public.
  public void prepareMockedData() {
              ^
    (see https://www.mycompany.com/utqg/HelperMethodCannotBePublic)
1 error

But there are a lot of UTQG:HelperMethodCannotBePublic errors that I would like to show to the user at same time. In the actual process, user must fix each of them separately because they are displayed separately. I also tried mvn -fae -fn options but without any success.

How can I handle it?

sergiofigueras avatar Jul 16 '16 12:07 sergiofigueras

It should show multiple errors within the same file, but the default behaviour is to stop after the first file with errors. If you want to get the full list of diagnostics, -Xep:HelperMethodCannotBePublic:WARN would allow compilation to continue past the first error.

cushon avatar Jul 16 '16 22:07 cushon

Hello @cushon :),

We are triggering our build using teamcity, and the developers should look at the results and see what's going on and how to fix it. But the fact is that:

  • we should display all errors, so developer can fix all errors instead of triggering different builds to do this.
  • the categorization of errors that errorprone provides (warning, error, etc) should be used in that case. So, if a BugChecker that's marked as error is described, it should fail the build.

How do you think that I could handle that? Should I specialize the compiler?

sergiofigueras avatar Jul 17 '16 22:07 sergiofigueras

As cushon said, you should change errors gravity to WARN for each error you got. I did the same in my build the first time I used error prone. I changed all these defaults and checked all of them at the end of the build process. You could have more errors, just add the error type each time the build fails. When you have done fixing all of them, remove every gravity override.

-Xep:SelfAssignment:WARN
-Xep:ReturnValueIgnored:WARN
-Xep:SizeGreaterThanOrEqualsZero:WARN
-Xep:ArrayToString:WARN
-Xep:DepAnn:WARN
-Xep:ComparisonOutOfRange:WARN
-Xep:GetClassOnClass:WARN
-Xep:FormatString:WARN
-Xep:DeadException:WARN

regrog avatar Jul 25 '16 10:07 regrog

#424 and the suggestion form @cushon would come in handy here

vanniktech avatar Jul 25 '16 10:07 vanniktech

We would also like a way to achieve this without marking errors as warnings. In fact, we use -Werror in our build on purpose to fail the build if error-prone reports anything. Now it would be nice if the reports from our CI build would include all problems and not only those from one file. Marking errors as warnings would mean the CI build would not be marked as failure at all, so this is not a solution.

PhilippWendler avatar Sep 07 '16 06:09 PhilippWendler

I had ran into the same issue. This is what worked in case anyone is still looking for a solution. <compilerArg>-XepAllErrorsAsWarnings</compilerArg> to bring down all the ERRORs to WARNs and then to make sure compiler shows warnings as well add

 <compilerId>javac-with-errorprone</compilerId>
          <showWarnings>true</showWarnings>

ajaygeorge avatar May 11 '18 03:05 ajaygeorge

I think we think this should have been fixed for most tools since Error Prone 2.3.2 (mentioned in https://github.com/google/error-prone/issues/1341#issuecomment-526546913) and that it will be fixed for Bazel in 8.0.0.

cpovirk avatar Jul 29 '24 15:07 cpovirk

Coincidentally, I saw some evidence today that -Werror does not output errors from multiple files with at least built-in javac warnings (as of JDK 22). It's possible that Error Prone warnings would suffer from the same problem in combination with -Werror nowadays, but I haven't checked. Actual Error Prone errors should at least be fixed as outlined in my previous post, even under JDK 22, I hope. (It works for us with an internal Bazel and an even newer javac, at least in the tests I've done.)

cpovirk avatar Jul 30 '24 18:07 cpovirk