Skip to content
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

[kotlin] K2 J2K: Avoid Using Any Type When Stricter Type is Known #2812

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

jocelynluizzi13
Copy link
Contributor

This PR tries to infer the true type of any JKNewExpression with an Any type argument. Meta has had many cases of types being set to Any? when that is clearly incorrect based on the information provided by that particular expression.

In TypeMappingConversion, we now run an extra step if the type argument is Any and the number of parameters matches the number of type arguments (since if they don't match, it's impossible to infer anything further). In that case, we:

  1. continue with the current type analysis if it's not Any or if the corresponding parameter type is null/unknown
  2. If the corresponding parameter type is not an Int (strong evidence of an indexing param, cannot use to infer type) or an arraytype (would need to get internal type which is harder to infer), use the parameter type instead
  3. If none of the above are true, only add the Any if there are multiple type arguments required. Otherwise, it's safer to just leave it out.

This will prevent errors such as the one in plugins/kotlin/j2k/shared/tests/testData/newJ2k/issues/kt-1048.kt and previously in noUnnecessaryAny.kt where the inferred type is clear but Any was used anyways

@ybedrov ybedrov added the kotlin Pull requests for Kotlin IntelliJ plugin label Jul 13, 2024
@abelkov abelkov self-assigned this Jul 17, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kotlin Pull requests for Kotlin IntelliJ plugin
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants