Question about preview and classfile versions

[Maurizio Cimadamore]

It seems to be that:

* Lint::isEnabled correctly reflects the command line flags
* Lint::isSuppressed does not

As such, isEnabled is correctly used in the constructor of Preview, to 
set the value of MandatoryWarningHandler::verbose.

But the isSuppressed check in Preview::warnPreview seems redundant, 
because no suppression will ever be found this way.

IMHO, Preview should not hold on to Lint after it uses it to initialize 
the MandatoryWarningHandler. The suppressions checks, where possible, 
should be left to clients (as code in Check etc. will be in a better 
position to know which Lint to actually use).

Alternalively, warnPreview could take a Lint as well, but then we'd have 
to think about how to model cases where no meaningful Lint exists 
(Scanner and Parser).

Maurizio

On 10/01/2025 17:58, Archie Cobbs wrote:
> On Fri, Jan 10, 2025 at 9:32 AM Archie Cobbs <archie.cobbs at gmail.com> 
> wrote:
>
>     On Fri, Jan 10, 2025 at 1:49 AM Jan Lahoda <jan.lahoda at oracle.com>
>     wrote:
>
>         I And the "lint" here is the "global" Lint instance, that
>         (AFAIK) never suppresses anything. I.e. the condition in the
>         "if" statement is always true, I believe.
>
>     The root Lint instance doesn't include any @SuppressWarnings
>     suppressions but it does include suppressions from command line
>     flags like -Xlint:-preview, so the "if" statement can be false.
>
>
> Oops - I am wrong about that. You are right - Lint.suppressedValues 
> does not get initialized from Xlint:-foo flags, only from 
> @SuppressWarnings annotations.
>
> And that also explains my bogus test for classfile minor versions.
>
> Thanks!
>
> -Archie
>
> -- 
> Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20250113/b5cbd0b9/attachment.htm>