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

PreferJavaTimeOverload generates false positive with jOOQ DSL.inline() #1504

Closed
tbroyer opened this issue Feb 6, 2020 · 0 comments · Fixed by #1511
Closed

PreferJavaTimeOverload generates false positive with jOOQ DSL.inline() #1504

tbroyer opened this issue Feb 6, 2020 · 0 comments · Fixed by #1511
Assignees

Comments

@tbroyer
Copy link
Contributor

tbroyer commented Feb 6, 2020

Description of the problem:

when using jOOQ's DSL.inline(1), ErrorProne emits a warning (which fails our build because we use -Werror)

warning: [PreferJavaTimeOverload] If the numeric primitive (1) represents a Instant, please call DSL.inline(Instant) instead.

Bugs: what's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

Simply call DSL.inline(1).

What version of Error Prone are you using?

2.3.4

Have you found anything relevant by searching the web?

PreferJavaTimeOverload seems to check the method return type when looking for overloads, but in this case DSL.inline(int) returns a Param<Integer> while DSL.inline(Instant) returns a Param<Instant>.
IMO, they should not be treated as the same return type.

@kluever kluever self-assigned this Feb 8, 2020
cpovirk pushed a commit that referenced this issue Feb 11, 2020
Fixes #1504

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=294228509
cpovirk pushed a commit that referenced this issue Feb 11, 2020
Fixes #1504

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=294228509
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 a pull request may close this issue.

2 participants