-
Notifications
You must be signed in to change notification settings - Fork 737
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
FormatStringAnnotation checker is annoyingly stricter than FormatString #4411
Comments
I agree the difference between When they were created, there were difference use-cases. It might be more principled to have stricter and less strict versions of both checks. But that also adds a fair bit of complexity, and isn't something there are plans to do at this point. Can you share any more background about what the real world use-case was where you encountered this, where you wanted to pass non-constant strings to a |
In our application we had several thousands of calls to In 99% of cases it doesn't matter, but occasionally this can cause bugs. To avoid rechecking all 5000 of calls, we just replaced But now we cannot use Error-Prone to autocheck our format strings, because it issues errors on ~50 calls (not too many, but I don't want to rewrite them out of principle, sort of) where it didn't have any complaints when we used As far as usecases go, 1) arguments may be fairly complex expressions, so one wouldn't want to repeat them in every |
In our project we use a simple custom wrapper over
String.format()
.Error-Prone has FormatStringAnnotation that would check for inconsistencies in format string, but unfortunately it is stricter (unwantedly) than FormatString. In other words, certain code that usesString.format()
gets accepted, but results in compilation error as soon as that is replaced with@FormatMethod
-annotated wrapper, with zero other changes.Testcase (I can attach a full Gradle project if wanted):
I don't see any reason why a call to a
@FormatMethod
-annotated method would be checked differently compared to a call toString.format()
.The text was updated successfully, but these errors were encountered: