[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.

To check if a field was writable, added more logic to expressions.kt:

1. count the number of writable usages as opposed to simply returning "yes" or "no". This allows us to account for JKStubExpression
2. Add asQualifiedAssignmentFromTarget expression. This checks for cases such as this.x = x and this.x++ that we were previously missing when using asAssignmentFromTarget alone. As such, we explicitly check that we are in either a constructor or a setter when applying this.

@abelkov @darthorimar @ermattt

[jocelynluizzi13]

It makes more sense to combine this with the fixValToVarDiagnosticBasedProcessing step given they can be fixed in the same place in the code.

Switching to draft until I complete that conversion

[jocelynluizzi13]

Modified this commit to fix things you pointed out earlier but also to add fixes for LocalVarToValInspectionBasedProcessing since while doing that I noticed additional test cases that should have been accounted for

[abelkov]

Please take a look at a failing test org.jetbrains.kotlin.nj2k.NewJavaToKotlinCopyPasteConversionTestGenerated#testComments

[abelkov]

For complex logic like this, I highly recommend to run your debug IDEA instance ("IDEA" run configuration) and try to convert some big files in intellij-community repository. See if we have some false positives/negatives.

[abelkov]

Overall, it's exciting to get rid of VarToValProcessing, because it is taking 8% of all J2K time in the K2 test suite. By contrast, ClassMemberConversion + InferMutabilityOfLocalVariables take just 150 ms out of 43 seconds.

[abelkov]

Also, please recheck testdata of org.jetbrains.kotlin.idea.inspections.CanBeValInspection, maybe there is something in there that we miss in J2K.

[jocelynluizzi13]

Tested in IDEA with ~10 files, things seem to be working well!

[abelkov]

Some tests are failing in

TextNewJavaToKotlinCopyPasteConversionTestGenerated
NewJavaToKotlinCopyPasteConversionTestGenerated

Please make sure to run all tests from j2k/k1.new/tests/test and j2k/k2/tests/test.

---

Also, I have converted some code from intellij.java.compiler.impl module and found many problems.

com.intellij.compiler.CompilerConfigurationImpl#convertPatterns:
False negative var ok

com.intellij.compiler.actions.MakeModuleAction#update:
False negative var presentationText (Nested ifs case, may be hard to do without proper control-flow analysis. We should at least have this case in J2K testdata)

com.intellij.compiler.impl.javaCompiler.javac.JavacOutputParser#processMessageLine:
False negative var colNum (some weird case with infinite loop)

com.intellij.compiler.impl.CompileDriver#createStatusMessage:
False negative "var message"

com.intellij.compiler.options.ModuleOptionsTableModel#setValueAt:
False positive: Val cannot be reassigned on item.option

com.intellij.compiler.options.ProcessorProfilePanel:
Many false positives: "Val cannot be reassigned"

com.intellij.compiler.progress.CompilerTask:
False positive: "Val cannot be reassigned" on myBuildViewService

com.intellij.compiler.server.impl.BuildProcessPreloadedStateClearer.ChangeProcessor#anyChange:
False positive myResult

com.intellij.compiler.server.BuildManager:
False positives

com.intellij.compiler.server.WslBuildCommandLineBuilder:
False positives

---

Please also see the Java inspections com.siyeh.ig.style.FieldMayBeFinalInspection and com.intellij.codeInspection.localCanBeFinal.LocalCanBeFinal (this one needs to be enabled explicitly so it works in your IDE). You may reuse some testdata, approaches or code from there. For example, we can do some easy checks with your custom code, and if all else fails - fallback to full Java control-flow analysis.