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

[jdunkerley]

Add a unconnected component

node3 = get 1

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

[JaroslavTulach]

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]

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]

@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]

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

[enso-bot]

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]

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]

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]

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]

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]

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.

[enso-bot]

Keziah Wesley reports a new STANDUP for the last Friday (2024-07-26):

Progress: Implemented type constructor and type-def parsers. It should be finished by 2024-07-31.

Next Day: Next day I will be working on the #10473 task. Recognize named-app syntax before applying operators.

[enso-bot]

Keziah Wesley reports a new STANDUP for the last Friday (2024-07-26):

Progress: Moved group construction later and implemented earlier named-app recognition. Added a warning when a syntactic operator is misused in an expression. It should be finished by 2024-07-31.

Next Day: Next day I will be working on the #10473 task. Address lints, update some backend and JS tests.

[enso-bot]

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

Progress: Testing. It should be finished by 2024-07-31.

Next Day: Next day I will be working on the #10473 task. Finish testing, updating backend tests.

[enso-bot]

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

Progress: Fixes for backend JVM tests, docs. It should be finished by 2024-07-31.

Next Day: Next day I will be working on the #10473 task. Finishing. Address some last lints.

[enso-bot]

Keziah Wesley reports a new STANDUP for today (2024-08-01):

Progress: Standard library test in CI revealed a complex precedence issue, fixed it and PR is green. It should be finished by 2024-08-02.

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

[enso-bot]

Keziah Wesley reports a new STANDUP for the last Friday (2024-08-02):

Progress: Implemented full named-application argument syntax, enabling misused-operator warnings. It should be finished by 2024-08-05.

Next Day: Next day I will be working on the #10473 task. Finish PR, start a GUI task.