Introduce Refaster rules that resolve EnumOrdinal violations
#1104
Conversation
|
Looks good. No mutations were possible for these changes. |
| /** Don't explicitly compare enums by their ordinal. */ | ||
| abstract static class ComparingEnum<E extends Enum<E>, T> { | ||
| @Placeholder(allowsIdentity = true) | ||
| abstract E toEnumFunction(@MayOptionallyUse T value); | ||
|
|
||
| @BeforeTemplate | ||
| @SuppressWarnings("EnumOrdinal" /* This violation will be rewritten. */) | ||
| Comparator<T> before() { | ||
| return comparingInt(v -> toEnumFunction(v).ordinal()); | ||
| } | ||
|
|
||
| @AfterTemplate | ||
| @UseImportPolicy(STATIC_IMPORT_ALWAYS) | ||
| Comparator<T> after() { | ||
| return comparing(v -> toEnumFunction(v)); | ||
| } | ||
| } |
There was a problem hiding this comment.
This will rewrite comparingInt(e -> e.getKey().ordinal()) to comparing(v -> v.getKey()). That result will not also be rewritten to comparingByKey(), because MapEntryComparingByKey matches against Map.Entry::getKey but not the associated lambda expression. This limitation applies to many of our rules, so fixing it is out of scope. (We should really "just" fix the MethodReferenceUsage check.)
I'm mentioning this because it'll prevent a cleanup opportunity in our internal code base, I see.
There was a problem hiding this comment.
Or combine this with OpenRewrite's https://docs.openrewrite.org/recipes/staticanalysis/replacelambdawithmethodreference if we can...
rickie
force-pushed
the
sschroevers/EnumOrdinal-resolutions
branch
from
de23007 to
0c48f7a
Compare
|
|
Looks good. No mutations were possible for these changes. |
Suggested commit message:
These rules resolve some of the violations reported by the EnumOrdinal check new in Error Prone 2.26.0.