[kotlin] K2 J2K: Move VarToValProcessing LocalVarToValInspectionBasedProcessing and fixValToVarDiagnosticBasedProcessing to JKTree

[jocelynluizzi13]

Removing VarToValProcessing LocalVarToValInspectionBasedProcessing and fixValToVarDiagnosticBasedProcessing from the postprocessor to make it more compatible with K2.

To do this, we will add mutability logic to the JKField class member conversion phase. Now, we will return IMMUTABLE for any private vars that do not have writable logic and are not JPA qualified. Note that StubExpressions are allowed to have 1 write, since this would be the initial assignment of the field.

This is consistently correct with when it has val, however it sometimes has var when it should be val. I have run out of ideas for ways to fix these false positives, and adding back the VarToValPostprocessing doesn't work because that consistently overcorrects (and was relying on the diagnostics to later revert back). For now, putting this up as a draft PR.

@abelkov @darthorimar @ermattt

(This is a simplification of #2702 because I deeply messed up the merge. Please see comments there for additional context)

[abelkov]

Sorry, I will probably have to review next week, as I'm trying to get my nullability prototype done!

[darthorimar]

Hello, and thank you for the PR :)

It looks like that implementing a custom 'find usages' on top of JKTree may not be the best solution in this case for the following reasons:

• Performance: This approach may necessitate multiple JKTree traversals, which could significantly impact performance.
• Complexity: 'Find usages' is a rather complex feature. It takes multiple months to properly implement it for the Kotlin Plugin using the IntelliJ IDEA API, and it also involves handling numerous potential corner cases.

Instead, I suggest that you utilize our existing functionality, specifically the mutability inference in Java. Please consider com.intellij.codeInspection.localCanBeFinal.LocalCanBeFinal.

Some logic from the LocalCanBeFinal inspection can be extracted and reused in JKTree. This would allow us to specify a JKLocalVariable mutability (so, val vs var) during its creation. Consequently, during JKTree conversion, we would already be aware of the mutability of all local variables during all conversion phases.

I'll be happy to discuss details and answer your questions :)