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

DistinctVarargsChecker produces a lot of false positives #4544

Open
pkoenig10 opened this issue Aug 20, 2024 · 4 comments
Open

DistinctVarargsChecker produces a lot of false positives #4544

pkoenig10 opened this issue Aug 20, 2024 · 4 comments

Comments

@pkoenig10
Copy link
Contributor

DistinctVarargsChecker only compares arguments using their textual representation, which is an unreliable way to determine if two arguments are equivalent.

For example, DistinctVarargsChecker emits a warnings for this code:

Set.of(UUID.randomUUID(), UUID.randomUUID())
@pkoenig10
Copy link
Contributor Author

pkoenig10 commented Aug 20, 2024

It looks like this has been the behavior since DistinctVarargsChecker was introduced, but I started seeing a lot more false positives after the change from #4449. I guess we frequently use Set.of and Map.of with these types of helpers methods.

@cushon
Copy link
Collaborator

cushon commented Aug 20, 2024

Thanks for the report.

I think there are a few places where checks make assumptions that methods are idempotent in situations like this. Another example is IdentityBinaryExpression where it discourages foo() && foo() even though foo() could be non-idempotent and return different results, and suggests refactoring for clarity if it's deliberate. I think it's reasonable to disagree about whether that's worth discouraging, I'm just trying to provide some background on the thinking behind the check.

Was the example you encountered literally Set.of(UUID.randomUUID(), UUID.randomUUID()), or is there any more context you can share about the false positives you encountered? Maybe there are heuristics that could be added to the check to cover some of the common cases.

@pkoenig10
Copy link
Contributor Author

pkoenig10 commented Aug 20, 2024

The examples I encountered weren't exactly that, but were effectively the same thing. This was primarily in test code where we were generating IDs and entities to for tests.

Set.of(createUserId(), createUserId())

I don't have any great ideas for a heuristic, I can see how you might want this check if the method being invoked here was something like an accessor.

@graememorgan
Copy link
Member

I think it's reasonable to disagree about whether that's worth discouraging, I'm just trying to provide some background on the thinking behind the check.

I think the other consideration (possibly the main one?) is that we'd have a spectacular quantity of false negatives if we only flagged provably-identical results.

We have some logic in ConstantExpressions to identify expressions which are guaranteed to produce the same result, but it requires listing known pure methods, which is a bit of a challenge.

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

No branches or pull requests

3 participants