8359596: Behavior change when both -Xlint:options and -Xlint:-options flags are given

[archiecobbs]

My minor contribution to #24746 (which fixed 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.

---

Progress

• Change must be properly reviewed (1 review required, with at least 1 Reviewer)
• Change must not contain extraneous whitespace
• Commit message must refer to an issue
• Change requires CSR request JDK-8359844 to be approved

Issues

• JDK-8359596: Behavior change when both -Xlint:options and -Xlint:-options flags are given (Bug - P2)
• JDK-8359844: Behavior change when both -Xlint:options and -Xlint:-options flags are given (CSR)

Reviewers

• Uwe Schindler (@uschindler - Author)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/25840/head:pull/25840
$ git checkout pull/25840

Update a local copy of the PR:
$ git checkout pull/25840
$ git pull https://git.openjdk.org/jdk.git pull/25840/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 25840

View PR using the GUI difftool:
$ git pr show -t 25840

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/25840.diff

Using Webrev

Link to Webrev Comment

[bridgekeeper]

👋 Welcome back acobbs! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

[openjdk]

❗ This change is not yet ready to be integrated.
See the Progress checklist in the description for automated requirements.

[openjdk]

@archiecobbs The following label will be automatically applied to this pull request:

• compiler

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command.

[mlbridge]

Webrevs

• 01: Full - Incremental (9e788319)
• 00: Full (8dcea700)

[jddarcy]

/csr needed

[openjdk]

@jddarcy has indicated that a compatibility and specification (CSR) request is needed for this pull request.

@archiecobbs please create a CSR request for issue JDK-8359596 with the correct fix version. This pull request cannot be integrated until the CSR request is approved.

[uschindler]

Adding isDisabled() looks fine to me.

Possibly at a later stage we should centralize all the handling using an EnumSet which is populated only once before the compiler is invoked.

The behaviour should be documented in the javac documentation.

[mcimadamore]

I generally agree with these changes, but I'm not sure that the code in Lint (which is not shown in this diff as it has not changed) really adheres to the policy described in the JBS issue that "last option should win". What Lint seems to do is to compute an initial set, like follows:

• if none is found, start from the empty set
• if all is found, start from the "everything" set
• if neither is found, start from a "predefined" set which contains some default categories

After that, the initial set is augmented (or reduced) based on the explicit enable/disable options.

I see at least two issues in this logic:

• how is the initial set determined if both all and none are specified? The "last win" policy might suggest that we use the last of these to determine the initial set, but the code doesn't do that, and I think it gives precedence to all.
• what if the same category is both enabled and disabled? Well, again, the code doesn't really apply a "last win" policy -- instead, for each category, we do this:

// Look for specific overrides
        for (LintCategory lc : LintCategory.values()) {
            if (options.isExplicitlyEnabled(Option.XLINT, lc)) {
                values.add(lc);
            } else if (options.isExplicitlyDisabled(Option.XLINT, lc)) {
                values.remove(lc);
            }
        }

That is, for each category we check if it's enabled -- if so we add it to the set. Otherwise if it's disabled, we remove it from the set. So, if a category is both enabled and disabled, it looks like the code should just treat it as enabled?

So, I'm not sure how this fix (or even the previous code, before we changed any of this) adheres/adhered to the "last win" policy?

[mcimadamore]

I generally agree with these changes, but I'm not sure that the code in Lint (which is not shown in this diff as it has not changed) really adheres to the policy described in the JBS issue that "last option should win". What Lint seems to do is to compute an initial set, like follows:

* if `none` is found, start from the empty set

* if `all` is found, start from the "everything" set

* if neither is found, start from a "predefined" set which contains some default categories

After that, the initial set is augmented (or reduced) based on the explicit enable/disable options.

I see at least two issues in this logic:

* how is the initial set determined if both `all` and `none` are specified? The "last win" policy might suggest that we use the last of these to determine the initial set, but the code doesn't do that, and I think it gives precedence to `all`.

* what if the same category is both enabled and disabled? Well, again, the code doesn't really apply a "last win" policy -- instead, for each category, we do this:

// Look for specific overrides
        for (LintCategory lc : LintCategory.values()) {
            if (options.isExplicitlyEnabled(Option.XLINT, lc)) {
                values.add(lc);
            } else if (options.isExplicitlyDisabled(Option.XLINT, lc)) {
                values.remove(lc);
            }
        }

That is, for each category we check if it's enabled -- if so we add it to the set. Otherwise if it's disabled, we remove it from the set. So, if a category is both enabled and disabled, it looks like the code should just treat it as enabled?

So, I'm not sure how this fix (or even the previous code, before we changed any of this) adheres/adhered to the "last win" policy?

Ok, I see that this change only really affects how options behave (and few other lint warnings). After debugging, I can clearly see that my analysis above is correct, and that the way in which the set of enabled lint warnings is computed does NOT conform to a "last win" policy. So, if you compile the code below with -Xlint:unchecked -Xlint:-unchecked:

class Test<X> {
    static void m(Test t) {
        Test<String> ts = t;
    }
}

It does print the lint warning (meaning that Werror would make this fail, even though the last lint command passed disables unchecked warnings).

So, the real fix of this PR is in using isDisabled instead of isExplicitlyDisabled. But I must notice that this carves out a special expection for options and path lint warnings -- whereas every other lint warning will not resolve "conflicts" in the same way.

[archiecobbs]

So, the real fix of this PR is in using isDisabled instead of isExplicitlyDisabled. But I must notice that this carves out a special expection for options and path lint warnings -- whereas every other lint warning will not resolve "conflicts" in the same way.

Correct - because that "carve out" was already there in the previous behavior, and the whole point of this patch is to restore that previous behavior.

Some lint warnings simply don't follow the normal enable/disable logic (which you normally get by using Lint.logIfEnabled()) and this is one of them. It would be nice to eliminate these special exceptions over time, but (as revealed by the associated bug) doing so breaks expectations that are built into various folks' build processes. So it's a nice thought but obviously outside of the scope of this PR.

Instead, what I'm trying to do now (in upcoming PR #24584) is simply make these special cases more explicit in the code using new DiagnosticFlag's; see for example this change.

[mcimadamore]

Ok, I now see that #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?

[mcimadamore]

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?

Note: the same is true for the new methods isEnabled/isDisabled added in this PR -- they feel Lint-specific methods to me.

[archiecobbs]

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?

Note: the same is true for the new methods isEnabled/isDisabled added in this PR -- they feel Lint-specific methods to me.

It's to allow for future customization of other lint-related options, in particular -Werror - see #23622.

Maybe that's a little too leading? I can remove it if you prefer.

[mcimadamore]

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?

Note: the same is true for the new methods isEnabled/isDisabled added in this PR -- they feel Lint-specific methods to me.

It's to allow for future customization of other lint-related options, in particular -Werror - see #23622.

Maybe that's a little too leading? I can remove it if you prefer.

Yeah, I think for now I'd prefer that. I believe each PR should be relatively standalone -- maybe we will go ahead and follow up with the other PR, but I'd prefer to avoid adding more stuff here which is really needed to support that other task.