search

enso-org / enso

Hybrid visual and textual functional programming.
https://enso.org
Apache License 2.0
7.31k stars 317 forks source link

Inconsistent imports #10399

Open Akirathan opened 4 days ago

Akirathan commented 4 days ago

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 https://github.com/enso-org/enso/blob/c9f0a36e2ec867c4fe2b346890c78fff3beaa265/engine/runtime-integration-tests/src/test/scala/org/enso/compiler/test/semantic/ImportExportTest.scala#L291 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.