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

Report all ref comparisons: use property to report all ref comparisons when set #2988

Merged
merged 25 commits into from
Jul 10, 2024

Conversation

miguel-vila
Copy link
Contributor

@miguel-vila miguel-vila commented May 16, 2024

Could try creating an example to minimally reproduce this, but thought it might be faster to open a PR with the changes I think are needed.

Basically, was trying to get all the RC_REF_COMPARISONs without needing to list all classes. Found the findbugs.refcomp.reportAll property in the Analysis properties page. Looking at the code, I noticed this property is not read (it was commented out) and added a few lines that would emit the warning if set.

Let me know if this makes sense.

@miguel-vila miguel-vila marked this pull request as ready for review May 16, 2024 16:57
Copy link
Collaborator

@JuditKnoll JuditKnoll left a comment

Choose a reason for hiding this comment

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

Thank you for your PR.
The build is failing because of some indentation issues, please run gradlew spotlessApply to solve them.
Also, can you please add a test, which this PR fixes?

@miguel-vila
Copy link
Contributor Author

@JuditKnoll thank you, I've added a couple of simple tests, you will notice I had to make a change in order to make this testeable.

I'm not familiar with bcel, but is there a way to identify if a ReferenceType refers to an enumeration? it would be good to not emit this warning in case it's enumeration values the ones being compared with == as this should be OK in that case.

@hazendaz
Copy link
Member

Am I correct in reading this that it was always 'true' before this change for reportAll, now it will be false by default? I think we should at least adhere to the current default if that is the case.

@miguel-vila
Copy link
Contributor Author

miguel-vila commented May 22, 2024

@hazendaz it was true but it was not reading the system property. I think the reportAll change is not enough to make this work and that's why I modified checkRefComparison with another if-clause. It seems to me that reportBest receives the result of calling checkRefComparison. If none of the clauses are true, then nothing gets added and reportAll won't report anything even if the reportAll flag is true.

Edit: I removed the clause at 66e6659 just to showcase that the test fails without it

@miguel-vila
Copy link
Contributor Author

@JuditKnoll @hazendaz let me know if this looks good or if there's anything to address

@miguel-vila
Copy link
Contributor Author

hi, any update on when this can be merged and released?

@hazendaz
Copy link
Member

hazendaz commented Jun 6, 2024

@miguel-vila Hi, my concern is that line 890 expects the current default of 'true'. Since now it expects a system variable, I'm presuming that variable is not there by default ? If it is not there by default, that breaks how this works today and thus would need to wait until we move to version 5. If you want this in the next release which I think probably will happen this weekend, I'd suggest leaving the default 'true' as it is today instead of now 'false'. That assumes my assumption on this is accurate but just from a code perspective it seems to be a breaking change.

@miguel-vila
Copy link
Contributor Author

@hazendaz hmmm, I assume your concern is that this doesn't have the same behaviour as the previous code?

So in order to preserve the default behaviour before (around if(reportAll)) we could make this env var have a default value of true? I have done this at c798376, but I think we are still bringing new behaviour with else if (reportAllRefComparisons()) {.

(btw I don't think I understand the if(reportAll) case or how to trigger it, it is not covered by my tests)

Is there a series branch for 5, or how do you keep the code targetting that version? When are you expecting to release that version?

@hazendaz
Copy link
Member

hazendaz commented Jun 7, 2024

@miguel-vila I'm good now with that. I'm unsure how the original code works but we have had so many mishaps lately that we should try our best not to break the original expectations. Main thing there was that it had that check expecting true there so if not present that was the original processing. I'm completely ok with your new processing otherwise. I just wanted to error on side of caution since the first path would have changed. Now it should remain the same.

We don't have a specific 5.x branch yet. Since we have had a number of issues in recent releases, we have been trying to stabilize before we jump as we will be changing the java version. Unfortunately we don't have a lot of active contributors at the moment so moving to 5.x has been slower than expected.

If @JuditKnoll, @ThrawnCA, and @gtoison all are ok on this, I'm ok with it coming in for 4.8.6. I think unless anyone has something else that we cut this weekend as it has a couple of fixes otherwise over last release. I know there are still some issues so 4.8.x might drag on a while longer in general but trying to get what works out the door in general.

@hazendaz
Copy link
Member

hazendaz commented Jun 7, 2024

@miguel-vila Can you check the new failures?

@hazendaz hazendaz self-assigned this Jun 7, 2024
@miguel-vila
Copy link
Contributor Author

looked into this. By making the variable have a default value of true, this error surfaced:

Exception analyzing edu.umd.cs.findbugs.FindBugsCommandLine using detector edu.umd.cs.findbugs.detect.FindRefComparison
    java.lang.IllegalArgumentException: Invalid class name edu/umd/cs/findbugs/config/AnalysisFeatureSetting[]
...

it was trying to instantiate Ledu/umd/cs/findbugs/config/AnalysisFeatureSetting[]; as a class descriptor (for an array field in FindBugsCommandLine), when the correct shape should be [Ledu/umd/cs/findbugs/config/AnalysisFeatureSetting;. I added that as a workaround, but not sure if there would be a better place for this (the whole "L" + ClassName.toSlashedClassName(lhs) + ";" was already suspicious).

Other than that, after enabling this it turns out spotbugs codebase itself has 34 cases of ref comparisons, so:

  • setting the default value to true will bring new behaviour, which will force users to fix or ignore those comparisons. Is this OK?
  • if this is OK, should we fix those comparisons in spotbugs?

@miguel-vila
Copy link
Contributor Author

oh no, it's not 34 cases, it's like 397 😬

@miguel-vila
Copy link
Contributor Author

@gtoison I have made some changes: the new if statement will emit with EXP_PRIORITY, which seems to translate to warnings with low confidence. Would this make the new if statement not break existing code?

Copy link
Contributor

@gtoison gtoison left a comment

Choose a reason for hiding this comment

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

The changes look good to me, thank you for the contribution!

@miguel-vila
Copy link
Contributor Author

@gtoison if we want to use this, would we need to set the priority to -low? that might get us a set of new warnings as well, right?

@gtoison
Copy link
Contributor

gtoison commented Jun 24, 2024

Good question! I think one way is to set the priority to low and then add a filter to exclude all low priority bugs, except for that one

Comment on lines +233 to +235
public static void removeProperty(String name) {
properties.remove(name);
}
Copy link
Collaborator

Choose a reason for hiding this comment

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

I'm not really fond of adding a new function just for the sake of tests. However, I don't know how else could this be tested without significant structural modification.

private void assertRefCompBug(String method, int line, Confidence confidence) {
final BugInstanceMatcher bugInstanceMatcher = new BugInstanceMatcherBuilder()
.bugType("RC_REF_COMPARISON")
.inClass("RefComparisons")
Copy link
Collaborator

@JuditKnoll JuditKnoll Jun 25, 2024

Choose a reason for hiding this comment

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

Are you sure that it's in this class every time? Even when it's in the inner class RefComparisons$MyClass3?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

hmm, I added a class parameter to this method to make this more explicitly, but I think it should be OK. I first check the total number of bugs (no matter the class) and then I use this method to check for each one of them.

@miguel-vila
Copy link
Contributor Author

hi, any update on whether this can be merged as it is, or should I address anything?

@hazendaz hazendaz added this to the SpotBugs 4.9.0 milestone Jul 10, 2024
@hazendaz hazendaz merged commit 01b6bcc into spotbugs:master Jul 10, 2024
15 checks passed
@miguel-vila
Copy link
Contributor Author

thanks for merging, when is the next planned release?

@hazendaz
Copy link
Member

possibly next week. no real timetable but that might work.

@miguel-vila
Copy link
Contributor Author

@hazendaz any update on when the next release is going to be? I see this PR was added to the 4.9.0 milestone

@hazendaz
Copy link
Member

hazendaz commented Aug 9, 2024

Hi, not entirely sure. I've meant to get to it but haven't found time yet. Possibly one of the other members might pick it up for release. I believe we have to discuss first though as I believe we skipped commons-lang update a few releases so at very minimum the changes need to be reviewed before we but it. That could easily take any one of us a day to review. Will try to get it soon though as I though I could get it last month and still haven't. Sorry for delays.

@ghostbuster91
Copy link
Contributor

@hazendaz Is there anything that we could help with to get this released?

@hazendaz
Copy link
Member

not really. any one of the core members can release but think we are all pressed for time elsewhere. I can try to look this weekend but do note that I'm spread really thin on things at the moment so if @gtoison or @JuditKnoll could do it, that would work but think they are in same boat at the moment. We are also discussing giving up on java 8 and jumping straight to 17 given we have taken a good deal of time this time around.

@kubukoz
Copy link

kubukoz commented Dec 6, 2024

Kindly requesting an update - I understand that this is an open source project and we all have other priorities, but it's blocking us @ work and we'd greatly appreciate a release 😅 looks like the milestone is all done.

Thanks in advance!

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

7 participants