TLDR: The type parameters will have the wrong JavaType.
Info:
When the PSI visits the name of the type parameters, an FIR association will not be found.
The PSI will traverse the parent nodes until it matches the most outer parameterized type.
I.E. The name String in List<String> will climb from String up to List<String> or the name Int of Map<Map<Int, Int>, Map<String, String>> will climb up to Map<Map<Int, Int>, Map<String, String>>.
Note: This may be caused by referencing the wrong PSI element and might be fixable using PSI-Utils from each visit that creates type parameters for parameterized types. The elementMap in PsiElementAssociations should be checked first to determine if we only need to revise the mapping instead of anything more complex.
@Test
void multiDepthParameterizedType() {
rewriteRun(
kotlin(
"""
val map: Map<Map<Int, Int>, Map<String, String>> = mapOf()
""", spec -> spec.afterRecipe(cu -> {
new KotlinIsoVisitor<Integer>() {
@Override
public J.Identifier visitIdentifier(J.Identifier identifier, Integer integer) {
// Identifier should be a JavaType.Class, but it will be a JavaType.Parameterized.
return super.visitIdentifier(identifier, integer);
}
}.visit(cu, 0);
})
)
);
}
TLDR: The type parameters will have the wrong JavaType.
Info: When the PSI visits the name of the type parameters, an FIR association will not be found. The PSI will traverse the parent nodes until it matches the most outer parameterized type. I.E. The name
String
inList<String>
will climb fromString
up toList<String>
or the nameInt
ofMap<Map<Int, Int>, Map<String, String>>
will climb up toMap<Map<Int, Int>, Map<String, String>>
.Note: This may be caused by referencing the wrong PSI element and might be fixable using PSI-Utils from each visit that creates type parameters for parameterized types. The
elementMap
in PsiElementAssociations should be checked first to determine if we only need to revise the mapping instead of anything more complex.