Repository navigation
Keep the method type in sync when recipes change a method's return type expression - #1193
Merged
Merged
Conversation
…e expression BeanMethodReturnNull, PreciseBeanType, MigrateAuditorAwareToOptional, MigrateJobParameter and MigrateWebMvcConfigurerAdapter replaced a method declaration's return type expression but left its JavaType.Method returning the old type. A shared helper now updates both, giving the declaration and its name the same method type instance.
The array branch replaced only the element type expression, gave it the array type, and left the J.ArrayType with the old type, so the method kept its old return type and the recipe ran a second cycle. Its import removal guard also tested the element TypeTree instead of its type, so the old element import was never removed.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Five recipes replace a method declaration's return type expression but leave its
JavaType.Methodreturning the old type. AFindMissingTypescheck proposed in openrewrite/rewrite#9284 compares the two on everyRewriteTestoutput. Against that branch, 10 tests inBeanMethodReturnNullTest,PreciseBeanTypeTest,MigrateAuditorAwareToOptionalTest,MigrateJobParameterTestandMigrateWebMvcConfigurerAdapterTestfail like this:A new helper,
MethodDeclarations.withReturnTypeExpression(md, typeTree)inorg.openrewrite.java.spring.internal, replaces the expression and updates the method type's return type to match. All eight call sites in the five recipes now use it:The declaration and its name get the same updated
JavaType.Methodinstance, becauseFindMissingTypesalso checks that the name's type is the declaration's method type. The helper uses only API that is already released, so these recipes can be fixed before #9284 merges.PreciseBeanType's array branch narrowed only the text
For
List[] bean1() { return new ArrayList[0]; }the array branch had two bugs:J.ArrayTypetypedList[]. The method kept returningList[], so the recipe ran a second cycle. The new check misses this because the expression and the method type are equally stale.TypeTreeinstead of the element's type, soimport java.util.Listwas never removed.The new test
PreciseBeanTypeTest.arrayTypecovers both bugs. It failed with "took 2 cycles" before the fix. I confirmed it catches the import bug by putting the old guard back temporarily. The 10 existing tests above pass against #9284 with this change, and all tests in the five classes pass against the published snapshot.