Compiler Internal Error: Impossible here, static method get should be caught when translating application

jdunkerley commented 3 months ago

Add a unconnected component

node3 = get 1

And you get the above internal error and things don't work right

JaroslavTulach commented 3 months ago

It would be interesting to know the whole source code. Without the source code, I can only guess what could be the problem. Trying to parse:

node3 = get 1

yields:

e.enso:1:9: error: The name `get` could not be found.
    1 | node3 = get 1
      |         ^~~

that's correct.

JaroslavTulach commented 3 months ago

This is the failing test:

diff --git engine/runtime-integration-tests/src/test/java/org/enso/compiler/ExecCompilerTest.java engine/runtime-integration-tests/src/test/java/org/enso/compiler/ExecCompilerTest.java
index d83891b7b5..b2ebe5bc4f 100644
--- engine/runtime-integration-tests/src/test/java/org/enso/compiler/ExecCompilerTest.java
+++ engine/runtime-integration-tests/src/test/java/org/enso/compiler/ExecCompilerTest.java
@@ -90,6 +90,25 @@ public class ExecCompilerTest {
     }
   }

+  @Test
+  public void testDoubleAssignmentError() throws Exception {
+    var module =
+        ctx.eval(
+            LanguageInfo.ID,
+            """
+    from Standard.Base import all
+
+    main =
+        node1 = node3 = get 3
+    """);
+    try {
+      var run = module.invokeMember("eval_expression", "main");
+      fail("Unexpected result: " + run);
+    } catch (PolyglotException ex) {
+      assertEquals("", ex.getMessage());
+    }
+  }
+
   @Test
   public void testDesugarOperatorsLeftRight() throws Exception {
     var module = ctx.eval(LanguageInfo.ID, """

it was actually pretty tricky to find the test case, as the same program yields normal compilation errors when executed from CLI. One really has to run in IDE's "non-strict errors" mode.

JaroslavTulach commented 3 months ago

@kaz, the node3 = get 3 in node1 = node3 = get 3 is represented as application of function/operator named =. Is that desirable? Shouldn't = be a reserved keyword and not an operator?

The question is who should reject that syntax? parser? TreeToIr? Or some later phase in the compiler?

The error is yielded from here and I can generate better syntax error, but possibly we should not even get to this place.

kazcw commented 3 months ago

That would be a syntax error. Only the parser should create syntax errors.

enso-bot[bot] commented 3 months ago

Keziah Wesley reports a new STANDUP for yesterday (2024-07-18):

Progress: Finished implementation; updated libraries; added new linter to run tool and CI. It should be finished by 2024-07-24.

Next Day: Next day I will be working on the #10473 task. Refactored syntactic-operators. Started working toward parser-only separation of tree type by contexts.

enso-bot[bot] commented 3 months ago

Keziah Wesley reports a new STANDUP for today (2024-07-19):

Progress: Introducing wrapper types for contexts and unifying context management around the new type conversions. It should be finished by 2024-07-24.

Next Day: Next day I will be working on the #10473 task. Continue refactoring contextualizing logic into the wrapper operations.

enso-bot[bot] commented 3 months ago

Keziah Wesley reports a new STANDUP for yesterday (2024-07-22):

Progress: Refactored syntactic operators. It should be finished by 2024-07-24.

Next Day: Next day I will be working on the #10473 task. Continue contextualizing refactor.

enso-bot[bot] commented 3 months ago

Keziah Wesley reports a new STANDUP for today (2024-07-23):

Progress: Implemented JNI bindings for warnings, worked on context PR. It should be finished by 2024-07-24.

Next Day: Next day I will be working on the #10473 task. Continue contextualizing refactor.

enso-bot[bot] commented 3 months ago

Keziah Wesley reports a new STANDUP for yesterday (2024-07-24):

Progress: Deferred parsing of all blocks and groups until their context is known. Started implementing statement parser. It should be finished by 2024-07-24.

Next Day: Next day I will be working on the #10473 task. Continue contextualizing refactor.

enso-bot[bot] commented 3 months ago

Keziah Wesley reports a new STANDUP for today (2024-07-25):

Progress: Implemented statement parser. It should be finished by 2024-07-31.

Next Day: Next day I will be working on the #10473 task. Eliminate remaining uses of OPR for non-expressions.