RFR: 8359596: Behavior change when both -Xlint:options and -Xlint:-options flags are given [v2]

[Maurizio Cimadamore]

On Wed, 18 Jun 2025 21:12:12 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> My minor contribution to #24746 (which fixed [JDK-8354556](https://bugs.openjdk.org/browse/JDK-8354556)) accidentally introduced a change in the compiler's behavior when given conflicting lint flags like `-Xlint:options -Xlint:-options`. This PR restores the original behavior.
>> 
>> Although this might be considered a weird corner case, many build systems add flags in multiple stages and this can easily result in both flags being added, and so the behavior in this scenario needs to stay consistent. 
>> 
>> Basically the code was trying to be too clever; when the original logic is restored, the code gets simpler.
>
> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Ensure that "-Xlint:none" still works for the affected warnings.
>   
>   The extra checks for "-Xlint:none" are needed now because of JDK-8352612,
>   which changed the behavior of "-Xlint:none" to no longer imply "-nowarn",
>   which allowed the affected warnings to get away with skipping that check.

Ok, I now see that https://github.com/openjdk/jdk/pull/24746 did essentially two things:
1. introduced aliases to lint categories -- this resulted in having a new method `Options:;isExplicilyEnabled/Disabled` to check all possible aliases for a lint option.
2. consequently replace calls to `options.isSet(Option.XLINT_CUSTOM, lc.option)` with `options.isExplicitlyEnabled(Option.XLINT, lc)`

Part (2) is what created the issue, because by replacing `isSet/Unset` with `isExplicitEnabled/Disabled` we ended up changing behavior: the `isExplicitEnabled/Disabled` methods depend on a new `Options::isSet` method that takes a default value, and also look into stuff like `-Xlint:none/all` (which didn't happen before).

So, this PR reverts the behavioral changes, by having `isExplicitEnabled/Disabled` behave more like `isSet/isUnset` used to work previously, which seems ok.

I have to admit I don't really get why `isExplicitEnabled/Disabled` takes an `Option` parameter -- I see them always invoked with `Option.XLINT`. Because of that, I'm not even sure they belong much in `Options` at all -- an instance method on `LintCategory` which accepts `Options` would perhaps look simpler for clients?

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

PR Comment: https://git.openjdk.org/jdk/pull/25840#issuecomment-2996677326