Support Gradle incremental compilation

[kelloggm]

Since Gradle 4.7, Gradle has supported incremental compilation in the presence of annotation processors. The feature is opt-in on an annotation processor-by-annotation processor basis, however. I don't think the Checker Framework has "opted-in", but we should. (Or maybe we have and I didn't know!)

See the documentation here: https://docs.gradle.org/current/userguide/java_plugin.html#sec:incremental_annotation_processing

I think the Checker Framework counts as an "isolating annotation processor", which they define as one that only accesses the annotated type and anything reachable from the AST.

They also have two caveats that might be relevant to us:

• "[Incremental annotation processors] must not depend on compiler-specific APIs like com.sun.source.util.Trees. Gradle wraps the processing APIs, so attempts to cast to compiler-specific types will fail. If your processor does this, it cannot be incremental, unless you have some fallback mechanism."
• "If you are using an annotation processor that reads resources (e.g. a configuration file), you need to declare those resources as an input of the compile task."

I suspect we are using some of the former. I don't know what they mean by "fallback mechanism", but we should investigate it. One place to start is the list of processors that do support Gradle, which is here: https://docs.gradle.org/current/userguide/java_plugin.html#state_of_support_in_popular_annotation_processors

The second means that users will need to declare stub files as resources, which is annoying, but not the end of the world.

[mernst]

The Checker Framework is heavily dependent on OpenJDK internals. It uses javac APIs and casts to javac types. This bodes ill for us.

Can you look into what a "fallback mechanism" is, and whether we can use one?

[MichalStehlikCz]

Lombok just unwraps ProcessingEnvironment and Filer; I have not found any usage of Filer in CheckerFramework and added unwrapping of processing environment, as it was needed by IntelliJ as well (#4068).

But it might cause incremental build to miss some changes relevant because of checker framework processing - if I understand it correctly, in theory, if only annotation processed by checker framework changes in some class, incremental build might fail to recompile dependent classes as it does not know that they also depend on said annotation. But it is only wild guess based on https://youtrack.jetbrains.com/issue/IDEA-250718 issue, I am definitely not an expert on incremental builds...