JVM: restore incorrect DFS logic in JavaModuleGraph for compatibility

The problem is tracked in KT-66622. It should be fixed later, with a
proper deprecation, because otherwise it can potentially break a lot of
code.

compiler/cli/cli-base/src/org/jetbrains/kotlin/cli/jvm/modules/JavaModuleGraph.kt

@@ -78,6 +78,9 @@ class JavaModuleGraph(finder: JavaModuleFinder) {
                     for ((dependencyModuleName, isTransitive) in module.moduleInfo.requires) {
                         if (dependencyModuleName == dependencyName) return true
                         if (isTransitive && dfs(dependencyModuleName)) return true
+
+                        // This is incorrect, but is left for compatibility, see KT-66622.
+                        if (isTransitive && dfs(dependencyName)) return true
                     }
                     return false
                 }

compiler/testData/javaModules/namedDoesNotReadAutomaticWithTransitiveStdlib/lib/foo/Foo.java

@@ -0,0 +1,3 @@
+package foo;
+
+public class Foo {}

compiler/testData/javaModules/namedDoesNotReadAutomaticWithTransitiveStdlib/main.fir.txt

@@ -0,0 +1 @@
+OK

compiler/testData/javaModules/namedDoesNotReadAutomaticWithTransitiveStdlib/main.txt

@@ -0,0 +1 @@
+OK

compiler/testData/javaModules/namedDoesNotReadAutomaticWithTransitiveStdlib/main/module-info.java

@@ -0,0 +1,3 @@
+module main {
+    requires transitive kotlin.stdlib;
+}

compiler/testData/javaModules/namedDoesNotReadAutomaticWithTransitiveStdlib/main/usage.kt

@@ -0,0 +1 @@
+val a = foo.Foo()

compiler/testData/javaModules/namedDoesNotReadAutomaticWithUnrelatedNamed/lib/foo/Foo.java

@@ -0,0 +1,3 @@
+package foo;
+
+public class Foo {}

compiler/testData/javaModules/namedDoesNotReadAutomaticWithUnrelatedNamed/main.fir.txt

@@ -0,0 +1 @@
+OK

compiler/testData/javaModules/namedDoesNotReadAutomaticWithUnrelatedNamed/main.txt

@@ -0,0 +1 @@
+OK

compiler/testData/javaModules/namedDoesNotReadAutomaticWithUnrelatedNamed/main/module-info.java

@@ -0,0 +1,5 @@
+module main {
+    requires kotlin.stdlib;
+
+    requires transitive unrelated;
+}

compiler/testData/javaModules/namedDoesNotReadAutomaticWithUnrelatedNamed/main/usage.kt

@@ -0,0 +1 @@
+val a = foo.Foo()

compiler/testData/javaModules/namedDoesNotReadAutomaticWithUnrelatedNamed/unrelated/module-info.java

@@ -0,0 +1,3 @@
+module unrelated {
+    exports unrelated;
+}

compiler/testData/javaModules/namedDoesNotReadAutomaticWithUnrelatedNamed/unrelated/unrelated/Unrelated.java

@@ -0,0 +1,3 @@
+package unrelated;
+
+public class Unrelated {}

compiler/testData/javaModules/namedReadsAutomaticWithUnrelatedAutomatic/lib/foo/Foo.java

@@ -0,0 +1,3 @@
+package foo;
+
+public class Foo {}

compiler/testData/javaModules/namedReadsAutomaticWithUnrelatedAutomatic/main.txt

@@ -0,0 +1 @@
+OK

compiler/testData/javaModules/namedReadsAutomaticWithUnrelatedAutomatic/main/module-info.java

@@ -0,0 +1,4 @@
+module main {
+    requires kotlin.stdlib;
+    requires unrelated;
+}

compiler/testData/javaModules/namedReadsAutomaticWithUnrelatedAutomatic/main/usage.kt

@@ -0,0 +1 @@
+val a = foo.Foo()

compiler/testData/javaModules/namedReadsAutomaticWithUnrelatedAutomatic/unrelated/unrelated/Unrelated.java

@@ -0,0 +1,3 @@
+package unrelated;
+
+public class Unrelated {}

compiler/tests/org/jetbrains/kotlin/jvm/modules/AbstractJavaModulesIntegrationTest.kt

@@ -387,4 +387,27 @@ abstract class AbstractJavaModulesIntegrationTest(
         val lib = module("lib", destination = File(tmpdir, name))
         module("main", additionalKotlinArguments = listOf("-classpath", lib.path))
     }
+
+    fun testNamedDoesNotReadAutomaticWithUnrelatedNamed() {
+        // This test should result in an error because 'main' does not depend on 'lib' or any other automatic module.
+        // But currently it's OK for compatibility, see KT-66622.
+        val lib = module("lib")
+        val unrelated = module("unrelated")
+        module("main", listOf(lib, unrelated))
+    }
+
+    fun testNamedDoesNotReadAutomaticWithTransitiveStdlib() {
+        // This test should result in an error because 'main' does not depend on 'lib' or any other automatic module.
+        // But currently it's OK for compatibility, see KT-66622.
+        val lib = module("lib")
+        module("main", listOf(lib))
+    }
+
+    fun testNamedReadsAutomaticWithUnrelatedAutomatic() {
+        // Similarly to how it works in javac, if we depend on one automatic module, we depend on all of them. So even though 'main' does
+        // not have explicit "requires lib", in fact it depends on 'lib' because it has "requires unrelated". So "OK" is expected.
+        val lib = module("lib")
+        val unrelated = module("unrelated")
+        module("main", listOf(lib, unrelated))
+    }
 }