RFR: 8344079: Minor fixes and cleanups to compiler lint-related code [v2]

Archie Cobbs acobbs at openjdk.org
Fri Nov 29 16:33:56 UTC 2024


On Fri, 29 Nov 2024 13:01:29 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> Question: why is this a separate class?

Simply because it foreshadows [the patch for JDK-8344159](https://github.com/archiecobbs/jdk/blob/suppression/src/jdk.compiler/share/classes/com/sun/tools/javac/code/LintSuppression.java), in which the file becomes a proper singleton responsible for tracking suppressions. Admittedly that's not really a good reason, so I'll fold these methods into `Lint.java` for this patch. Should be fixed in 7cb7aa0cd01.

> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Modules.java line 1365:
> 
>> 1363: 
>> 1364:             if (!incubatingModules.isEmpty()) {
>> 1365:                 log.warning(LintCategory.INCUBATING, null, Warnings.IncubatingModules(incubatingModules));
> 
> Thanks for fixing all these. IMHO the fact we had so many bad usages points at the fact that the system we use to report warning is a bit too loose. I wonder if we should differentiate warning keys from lint warning keys, and have lint warnings be reported with a dedicated method in `Log`, so that there can be no confusion as to which is which (this is for a separate, possible, future PR)

Agree... one of the best ways to ensure a policy is correctly followed is to make the build fail when it's not :)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22056#discussion_r1863752620
PR Review Comment: https://git.openjdk.org/jdk/pull/22056#discussion_r1863752769


More information about the compiler-dev mailing list