RFR: 8348427: DeferredLintHandler API should use JCTree instead of DiagnosticPosition [v2]

[Archie Cobbs]

On Wed, 5 Feb 2025 11:30:12 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> Question: what happens if we get rid of the "immediate" and we always defer? Does this only affect the order in which diagnostics are reported, or is there something deeper?

I learn a little bit more about this. It looks like the only time immediate mode is used explicitly (i.e., other due to `DeferredLintHandler`'s default state) is when resolving imports ([here](https://github.com/openjdk/jdk/blob/89e5e7ab73472b7d02aac5b8b0c7e9f26db6ec32/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TypeEnter.java#L368)). In that case, of course, there can be no enclosing `@SuppressWarnings` so that makes sense.

It looks like the other apparent use ([here](https://github.com/openjdk/jdk/blob/89e5e7ab73472b7d02aac5b8b0c7e9f26db6ec32/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Annotate.java#L257)) never occurs because `annotateLater()` is never invoked with a null `deferPos` (I've cleaned this up and added an assertion).

> This seems like a great plan. We don't have to get there in one step (and this PR can proceed separately). I just want to make sure that we end up somewhere around there :-)

I did some more exploration of this idea. The main trip-up at this point is the speculative compilation stuff, because in that case warnings that occur as a side effect should be discarded because they're not "real". This is done via `Log.DeferredDiagnosticHandler`. So my initial strategy of "Just defer all warnings and actually execute them later" is too simplistic (although I do have a prototype which "almost works" I'm happy to share). If/when you have time I'd like to discuss how to proceed with you. That discussion probably belongs somewhere else e.g. on compiler-dev or a draft PR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23281#issuecomment-2640782274