Repository navigation
Conversation
3f48996 to
1b578f4
Compare
|
This PR should also integrate #57 |
Theses messages can be generated by annotation processors using `printMessage(Diagnostic.Kind.NOTE, "...")`.
If the -log argument is used, the resulting log file is scanned for compiler output, both text and xml formatting supported. Otherwise a temporary log file is used to capture compiler output. * Unit tests refactored * Output emitted as "INFO" are reported as Kind.NOTE * Column count adjusted to be 1-based index
|
Actually, I'm not sure about including the |
|
For info, in Java 21, a note was added that span multiple lines (see https://inside.java/2023/07/29/quality-heads-up/). This produce the following output from javac: This should probably be handled in this PR when note level messages are parsed. Not sure what is the plan to merge this, but it would be really useful to have at least the note parsing, to handle this case when compiling with Java 21. Currently note messages are skipped, but this also only handle single line messages, so only the first line is skipped and the remaining lines are prepended with the next warning which is not a good output. |
slachiewicz
added
the
need-rebase
|
Splitting this so the uncontroversial part can move: #496 takes the javac half. It is not the one-line change from here — @spadou's multi-line JDK 21 note needs its continuation lines consumed, otherwise they poison the unclassified buffer, and since 880da00 that buffer is reported as a compiler error when javac fails. The other two commits here, #313 and #314, are long merged. That leaves the eclipse This comment was created with AI assistance. |
The two javac back-ends disagreed. In-process compilation maps Diagnostic.Kind.NOTE to CompilerMessage.Kind.NOTE, so notes reach the build log; the forked path threw them away with a comment about JDK 1.5 and -Xlint:deprecation. Forwarding them makes the two agree and brings back the "Recompile with -Xlint:deprecation for details" hints that #183 asks for. The idea, and the one-line form of it, come from #312. Notes cannot simply be emitted line by line. javac can wrap one over several lines, indenting every line but the first: Note: Annotation processing is enabled because one or more processors were found on the class path. A future release of javac may disable ... No classifier matches those continuation lines, so they landed in the unclassified buffer, and once that buffer is non-empty every following line joins it - which is why the note used to reappear glued to the front of the next warning. Since 880da00 a failing compile reports that buffer as an error, so a project with an annotation processor on the class path could get a compiler error assembled out of note text. A note is therefore held back until a line arrives that does not continue it. That particular note belongs to JDK 21 and 22 only: JDK 23 made annotation processing opt-in, and JDK 25 stays silent even with a processor on the class path. The handling is general because nothing stops a future note from wrapping. Do not tighten the continuation test into a match against the note's own wording, which is localised and changes between releases. Verified: mvn clean install on JDK 25, whole reactor green.
The two javac back-ends disagreed. In-process compilation maps Diagnostic.Kind.NOTE to CompilerMessage.Kind.NOTE, so notes reach the build log; the forked path threw them away with a comment about JDK 1.5 and -Xlint:deprecation. Forwarding them makes the two agree and brings back the "Recompile with -Xlint:deprecation for details" hints that #183 asks for. The idea, and the one-line form of it, come from #312. Notes cannot simply be emitted line by line. javac can wrap one over several lines, indenting every line but the first: Note: Annotation processing is enabled because one or more processors were found on the class path. A future release of javac may disable ... No classifier matches those continuation lines, so they landed in the unclassified buffer, and once that buffer is non-empty every following line joins it - which is why the note used to reappear glued to the front of the next warning. Since 880da00 a failing compile reports that buffer as an error, so a project with an annotation processor on the class path could get a compiler error assembled out of note text. A note is therefore held back until a line arrives that does not continue it. That particular note belongs to JDK 21 and 22 only: JDK 23 made annotation processing opt-in, and JDK 25 stays silent even with a processor on the class path. The handling is general because nothing stops a future note from wrapping. Do not tighten the continuation test into a match against the note's own wording, which is localised and changes between releases. Verified: mvn clean install on JDK 25, whole reactor green.
|
Closing as not planned: what this PR set out to do is on master, by other routes.
Two things here have no equivalent on master. Neither changes what a caller sees:
Either is welcome as its own change, and the work here is a good starting point for it. Thanks @gnodet, and sorry it sat this long. This comment was created with AI assistance. |
5 participants
Theses messages can be generated by annotation processors using
printMessage(Diagnostic.Kind.NOTE, "...").