Feature request: Support collecting non-error diagnostics

[Marcono1234]

Currently this library only considers error diagnostics (relevant source) and ignores all other diagnostic kinds.

Would it be possible to support collecting other diagnostic types as well (if explicitly configured)?

For example, for my use case I would like to know whether some generated code produces any compiler warnings (or other relevant diagnostics). However, it is not that important, so I can understand if you don't think it is worth it to support this feature.

[JerryShea]

@Marcono1234 it sounds like a useful feature, but not one that anyone else has requested. You are welcome to submit a PR which we will review.

[tgd]

Closing this out as no work is planned on this issue at the moment. Please comment on this issue if you would like it re-opened or even better if you have a PR in mind we would be very happy to review it.

[Marcono1234]

I was thinking about maybe adding a CachedCompiler#compileFromJava overload which takes an additional Set<Diagnostic.Kind>, and then print all diagnostics to the existing PrintWriter (similar to how it is done for the ERROR diagnostics currently).

And in case more than one diagnostic kind is specified (or always?) prefix the diagnostic with the kind name. And maybe in case the Set is empty use the current approach of only writing ERROR diagnostics.

Though I am not completely sure if that is a clean approach. And whether exposing Diagnostic.Kind in the public API is ok.

What do you think about this idea, or do you have something else in mind?
Maybe some kind of Consumer<Diagnostic<? extends JavaFileObject>> (or even javax.tools.DiagnosticListener<JavaFileObject>) would be even better so that they user has more control over how to process the diagnostics. If you want I can provide a proof-of-concept for this.

[Marcono1234]

@tgd, what do you think?

[JerryShea]

hi @Marcono1234, if you'd like us to prioritise then please review the support options. If you'd like to provide a PR then that would also be great - contributions are always welcome!

[Marcono1234]

@JerryShea, I have created #141 for a potential implementation of this. Please let me know what you think.