typetools / typetools/checker-framework
@FormatFor annotation
Nobody has claimed this yet.
- Dominant language
- Java
- Stars
- 1.1k
- Forks
- 440
- Avg merge
- 1d 12h
- Merged PRs (30d)
- 134
Description
This is a feature request to create a @FormatFor annotation to complement @FormatMethod
Here is code in Daikon that could use it:
private static void decl_error(
ParseState state, Throwable cause, String format, @Nullable Object... args) {
@SuppressWarnings(
"formatter:format.string.invalid") // need a @FormatFor annotation
String msg = String.format(format, args) + state.line_file_message();
throw new Daikon.UserError(cause, msg);
}
The @FormatFor annotation also enables the body of methods annotated as @FormatMethod to be type-checked.
Quoting from #1507:
Note a difference in the design of the Formatter and I18nFormatter type systems.
- Formatter has
@FormatMethod, which is more concise and easier to read and write. - I18nFormatter has
@I18nFormatFor.
At one point, the Formatter type system had @FormatFor, but I recall that it was removed in favor of @FormatMethod. It seems that @FormatFor is needed as well; the type-checker could add it in the appropriate place whenever the user has written @FormatMethod. An alternative would be to check, within method m, whether the arguments to a format method are formal parameters of m and m is annotated as @FormatMethod. This would not take advantage of the dataflow framework, however.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the @FormatMethod and proposed @FormatFor designs in this issue, then read the referenced discussion in #1507. Determine how the Formatter type system should represent the relationship and how the type-checker should apply it; the work is done when the annotation and its intended checking behavior are supported.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java
- Domain
- devtools
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 30/100