Inconsistent import and FQN #9329
Comments
|
I managed to get the diff --git engine/runtime/src/main/java/org/enso/interpreter/node/callable/InvokeMethodNode.java engine/runtime/src/main/java/org/enso/interpreter/node/callable/InvokeMethodNode.java
index 0998e55277..fe1cc688d6 100644
--- engine/runtime/src/main/java/org/enso/interpreter/node/callable/InvokeMethodNode.java
+++ engine/runtime/src/main/java/org/enso/interpreter/node/callable/InvokeMethodNode.java
@@ -210,6 +210,25 @@ public abstract class InvokeMethodNode extends BaseNode {
Type selfTpe = typesLibrary.getType(self);
Function function = resolveFunction(symbol, selfTpe, methodResolverNode);
if (function == null) {
+ if (self instanceof Type t && t.getDefinitionScope().getAssociatedType() == t) {
+ CompilerDirectives.transferToInterpreter();
+ // if we represent a Module
+ var scope = t.getDefinitionScope();
+ var module = scope.getModule();
+ var ctx = EnsoContext.get(this);
+ var moduleName =
+ module.getName().item().equals("Main")
+ ? module.getPackage().libraryName().toString()
+ : module.getName().toString();
+ var subModuleName = moduleName + "." + symbol.getName();
+ var optionModule = ctx.getTopScope().getModule(subModuleName);
+ if (optionModule.isPresent()) {
+ var subType = optionModule.get().getScope().getAssociatedType();
+ if (subType != null) {
+ return subType;
+ }
+ }
+ }
throw methodNotFound(symbol, self);
}
var resolvedFuncArgCount = function.getSchema().getArgumentsCount();I am not really satisfied with the above code - it seems too brutally direct. When investigating what import/export resolution does I found this stack: What the ImportResolver.tryResolveImport does?
I'd say the functionality of the above diff is similar. It also uses |
|
Might be a duplicate of #6553 |
|
I believe the proper fix is in the compilation phase rather than fixing the runtime behavior, namely in org.enso.compiler.pass.resolve.FullyQualifiedNames.scala introduced by #4056. It appears that this compiler pass is inconsistent with the Import/export resolver. |
|
Pavel Marek reports a new STANDUP for today (2024-03-11): Progress: - Looking into the problems with consistency between FQN and imports
|
|
Pavel Marek reports a new STANDUP for today (2024-03-12): Progress: - Making sure I correctly understand the requirements and what is expected from the engine.
|
|
Pavel Marek reports a new STANDUP for today (2024-03-14): Progress: - New BC assignment.
|
|
Pavel Marek reports a new STANDUP for today (2024-03-15): Progress: - Adding more tests that checks resolved symbols in BindingsMap
|
|
Pavel Marek reports a new STANDUP for today (2024-03-18): Progress: - Debugging the tests and other IR passes. Somehow, the IR pass is called twice on a clone of the expression IR??
|
|
Pavel Marek reports a new STANDUP for today (2024-03-19): Progress: - Discovered huge regressions in stdlibs benchmarks.
|
|
Same situation I see with when GUI sends |
|
Pavel Marek reports a new STANDUP for yesterday (2024-03-20): Progress: - Fixed some tests by modification of
|
|
Pavel Marek reports a new STANDUP for yesterday (2024-03-21): Progress: - Comming up with a simple GraphViz visualization tool for our IR.
|
|
Pavel Marek reports a new STANDUP for today (2024-03-22): Progress: - With the help of my recent IR visualization tool, I am finally able to see what is wrong with some passes.
|
|
Pavel Marek reports a new 🔴 DELAY for today (2024-03-25): Summary: There is 7 days delay in implementation of the Inconsistent import and FQN (#9329) task. As noted previous week, there is a delay on this issue. In past few days, I was just comming up with a way how to correctly understand the changes done to IR and medata between various Compiler passes. Delay Cause: Fixes on IR and metadata level are more complex and intertwined than expected. |
|
Pavel Marek reports a new STANDUP for today (2024-03-25): Progress: - Ensuring that code coverage is sufficient.
|
|
Pavel Marek reports a new STANDUP for today (2024-03-26): Progress: - Abandoning the original PR #9367 in favor of Jaroslav's runtime approach at #9539
|
As of Mar 8, 2024 there seems to be an inconsistency between
importand using fully qualified name in certain cases.When Main Does not Reexport Submodule
When Main in root of library doesn't re-export a submodule, then the module is not going to be accessible via FQN. Example where import works:
but where FQN access doesn't work:
and it yields
The same type of problem is also reported as #6553 - the FQN in question is
Standard.Database.Connection.Postgres_Details.Postgres_Details.Postgresin that case.Any Other Case?
Not known yet...
Requested Behavior
If
x.y.z.Acan be imported by such name, one shall be able to use the same name as FQN.The text was updated successfully, but these errors were encountered: