Closed jdunkerley closed 2 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.
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.
@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.
That would be a syntax error. Only the parser should create syntax errors.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
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.
Add a unconnected component
And you get the above internal error and things don't work right