Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Feature request: Support collecting non-error diagnostics #93

Closed
Marcono1234 opened this issue Jan 18, 2022 · 6 comments · May be fixed by #141
Closed

Feature request: Support collecting non-error diagnostics #93

Marcono1234 opened this issue Jan 18, 2022 · 6 comments · May be fixed by #141
Assignees
@peter-lawrey
Labels
enhancement

Comments

@Marcono1234
Copy link
Contributor

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
Copy link
Contributor

@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.

@peter-lawrey peter-lawrey self-assigned this May 24, 2023
@tgd
Copy link
Contributor

tgd commented Jun 3, 2024

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.

@tgd tgd closed this as not planned Won't fix, can't repro, duplicate, stale Jun 3, 2024
@Marcono1234
Copy link
Contributor Author

Marcono1234 commented Jun 16, 2024 •
edited
Loading

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
Copy link
Contributor Author

@tgd, what do you think?

@JerryShea
Copy link
Contributor

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 Marcono1234 mentioned this issue Jul 21, 2024
Open
@Marcono1234
Copy link
Contributor Author

Marcono1234 commented Jul 21, 2024 •
edited
Loading

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

@Marcono1234 Marcono1234 mentioned this issue Jul 21, 2024
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@peter-lawrey peter-lawrey

Labels
enhancement
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Support providing DiagnosticListener for compiling Marcono1234/Java-Runtime-Compiler
5 participants
@tgd @peter-lawrey @minborg @Marcono1234 @JerryShea