Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Do not report DLS_DEAD_LOCAL_STORE for java 21 type switch variables #2828

Merged
merged 7 commits into from Feb 3, 2024

Conversation

gtoison
Copy link
Contributor

@gtoison gtoison commented Jan 21, 2024

As noted in #2736 there's a mandatory variable in java 21 type switches, SpotBugs should not report DLS_DEAD_LOCAL_STORE when that variable remains unused.

switch (x) {
    case Map<?, ?> m -> return 1;
    default -> return 2;
}

Build on top of #2782 to detect that the problematic astore was part of a type switch and ignore it.

@gtoison gtoison marked this pull request as ready for review January 21, 2024 16:52
import org.apache.bcel.generic.Instruction;
import org.apache.bcel.generic.InstructionHandle;
import org.apache.bcel.generic.ASTORE;
import org.apache.bcel.generic.Instruction;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Line 31 and 34 are the same imports.

Comment on lines +279 to +283
switchHandler.enterSwitch(switchInstruction.getOpcode(),
pc,
indices,
0, // Not sure how to get the default offset from BCEL but it doesn't matter here
false); // It shouldn't matter here if the switch was exhaustive or not
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you please take a look at the definition of this method? The last parameter, which is a primitive boolean, has the annotation @CheckForNull.
It was added in #2813, which was already merged, but you are the author. Are you sure, that this was what you wanted?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have removed the @CheckForNull, I mistakenly carried it over when overloading the method

Comment on lines +266 to +267
InstructionHandle handle = location.getHandle();
int pc = handle.getPosition();
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's great that you moved these into separate variables. Can you please use these inside this method instead of retrieving it by calling the functions several times?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I actually moved these up because the variables were declared further down and I needed them for the new code.
If that's OK I'd like to keep the existing code untouched, so the changes are limited to fixing this false positive.

@@ -254,18 +262,41 @@ private void analyzeMethod(ClassContext classContext, Method method) throws Data
BugInstance pendingBugReportAboutOverwrittenParameter = null;
try {
WarningPropertySet<WarningProperty> propertySet = new WarningPropertySet<>();

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This method is quite long as it is, with this change, ranging from line 207 to 645. IMO it's worth considering moving some parts of it into separate functions. (Not necessarily in this PR.)

InstructionHandle handle = location.getHandle();
int pc = handle.getPosition();

if (handle.getInstruction() instanceof INVOKEDYNAMIC) {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe handle.getInstruction() also could be moved into a variable.

@gtoison
Copy link
Contributor Author

gtoison commented Jan 30, 2024

Thanks for reviewing @JuditKnoll, I have made some changes
Regarding the length/complexity of the method and the use of local variables I think these changes might be better in a separate PR, if we ever do them.

@hazendaz hazendaz self-assigned this Feb 3, 2024
@hazendaz hazendaz added this to the SpotBugs 4.8.4 milestone Feb 3, 2024
@hazendaz hazendaz merged commit d4380b3 into spotbugs:master Feb 3, 2024
10 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants