Inconsistent import X.Y.Z and from X.Y import Z

[Akirathan]

The two types of imports from project.Module import Something and import project.Module.Something should be semantically exactly the same. But they are not. For example, changing the line in the test in

enso/engine/runtime-integration-tests/src/test/scala/org/enso/compiler/test/semantic/ImportExportTest.scala

Line 291 in c9f0a36

|import $namespace.$packageName.My_Module.My_Type.Constructor

to

diff --git a/engine/runtime-integration-tests/src/test/scala/org/enso/compiler/test/semantic/ImportExportTest.scala b/engine/runtime-integration-tests/src/test/scala/org/enso/compiler/test/semantic/ImportExportTest.scala
index 7ac98a8890..5335ddfc75 100644
--- a/engine/runtime-integration-tests/src/test/scala/org/enso/compiler/test/semantic/ImportExportTest.scala
+++ b/engine/runtime-integration-tests/src/test/scala/org/enso/compiler/test/semantic/ImportExportTest.scala
@@ -288,7 +288,7 @@ class ImportExportTest
 
       val mainIr =
         s"""
-          |import $namespace.$packageName.My_Module.My_Type.Constructor
+          |from $namespace.$packageName.My_Module.My_Type import Constructor
           |""".stripMargin
           .createModule(packageQualifiedName.createChild("Main"))
           .getIr

will make the test fail.

The same is true for exports.

The reason for that is because ImportResolverAlgorithm.tryResolveImport does not consider the symbols in the from ... import <symbols> case at all. The algorithm should be improved to handle all the symbols from these kinds of imports as well. For that, we will most likely have to change the definition of the Result type parameter.