#3 Cannot parse inner fmu names with hyphen

Open
opened 3 years ago by casper · 2 comments
casper commented 3 years ago

It seems like the parser cannot handle inner fmu names with hyphen. Example: This SA:

semantic adaptation reactive moore RollbackTest rollbackTest_sa
at "./path/to/RollbackTest.fmu"

    for inner fmu rollback-end rollbackend
        at "./test_input/single_folder_spec/rollback_test/rollback-end.fmu"
        with input ports level

input ports level -> rollbackend.level
        
control rules {
    save_state(rollbackend);
    rollback(rollbackend);
    
    return 1;
}

Generates the following error:

java.lang.AssertionError: Expected no errors, but got :ERROR (org.eclipse.xtext.diagnostics.Diagnostic.Syntax) 'mismatched input 'rollback' expecting RULE_ID' on InnerFMU, offset 112, length 8
ERROR (org.eclipse.xtext.diagnostics.Diagnostic.Syntax) 'mismatched input 'at' expecting '->'' on Connection, offset 139, length 2
ERROR (org.eclipse.xtext.diagnostics.Diagnostic.Syntax) 'mismatched input 'input' expecting '->'' on Connection, offset 233, length 5
ERROR (org.eclipse.xtext.diagnostics.Diagnostic.Syntax) 'missing EOF at 'control'' on SemanticAdaptation, offset 275, length 7
ERROR (org.eclipse.xtext.diagnostics.Diagnostic.Linking) 'Couldn't resolve reference to Port 'rollbackend'.' on SpecifiedPort, offset 125, length 11
ERROR (org.eclipse.xtext.diagnostics.Diagnostic.Linking) 'Couldn't resolve reference to Port 'level'.' on SpecifiedPort, offset 226, length 5
ERROR (org.eclipse.xtext.diagnostics.Diagnostic.Linking) 'Couldn't resolve reference to Port 'level'.' on SpecifiedPort, offset 245, length 5
ERROR (org.eclipse.xtext.diagnostics.Diagnostic.Linking) 'Couldn't resolve reference to FMU 'rollbackend'.' on SpecifiedPort, offset 254, length 11
ERROR (org.eclipse.xtext.diagnostics.Diagnostic.Linking) 'Couldn't resolve reference to Port 'level'.' on SpecifiedPort, offset 266, length 5

    at org.junit.Assert.fail(Assert.java:88)
    at org.eclipse.xtext.testing.validation.ValidationTestHelper.assertNoErrors(ValidationTestHelper.java:142)
    at org.eclipse.xtext.testing.validation.ValidationTestHelper.assertNoErrors(ValidationTestHelper.java:48)
    at be.uantwerpen.ansymo.semanticadaptation.cg.cpp.tests.CgCppBasicTest.__assertNoParseErrors(CgCppBasicTest.java:237)
    at be.uantwerpen.ansymo.semanticadaptation.cg.cpp.tests.CgCppBasicTest.__parseNoErrors(CgCppBasicTest.java:159)
    at be.uantwerpen.ansymo.semanticadaptation.cg.cpp.tests.CgCppBasicTest.rollback_test(CgCppBasicTest.java:87)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
    at java.lang.reflect.Method.invoke(Unknown Source)
    at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
    at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
    at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
    at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
    at org.eclipse.xtext.testing.XtextRunner$1.evaluate(XtextRunner.java:49)
    at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
    at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
    at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
    at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
    at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
    at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
    at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
    at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
    at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
    at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86)
    at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
    at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)
    at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:678)
    at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)
    at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192)

It seems like the parser cannot handle inner fmu names with hyphen. Example: This SA: ``` semantic adaptation reactive moore RollbackTest rollbackTest_sa at "./path/to/RollbackTest.fmu" for inner fmu rollback-end rollbackend at "./test_input/single_folder_spec/rollback_test/rollback-end.fmu" with input ports level input ports level -> rollbackend.level control rules { save_state(rollbackend); rollback(rollbackend); return 1; } ``` Generates the following error: ``` java.lang.AssertionError: Expected no errors, but got :ERROR (org.eclipse.xtext.diagnostics.Diagnostic.Syntax) 'mismatched input 'rollback' expecting RULE_ID' on InnerFMU, offset 112, length 8 ERROR (org.eclipse.xtext.diagnostics.Diagnostic.Syntax) 'mismatched input 'at' expecting '->'' on Connection, offset 139, length 2 ERROR (org.eclipse.xtext.diagnostics.Diagnostic.Syntax) 'mismatched input 'input' expecting '->'' on Connection, offset 233, length 5 ERROR (org.eclipse.xtext.diagnostics.Diagnostic.Syntax) 'missing EOF at 'control'' on SemanticAdaptation, offset 275, length 7 ERROR (org.eclipse.xtext.diagnostics.Diagnostic.Linking) 'Couldn't resolve reference to Port 'rollbackend'.' on SpecifiedPort, offset 125, length 11 ERROR (org.eclipse.xtext.diagnostics.Diagnostic.Linking) 'Couldn't resolve reference to Port 'level'.' on SpecifiedPort, offset 226, length 5 ERROR (org.eclipse.xtext.diagnostics.Diagnostic.Linking) 'Couldn't resolve reference to Port 'level'.' on SpecifiedPort, offset 245, length 5 ERROR (org.eclipse.xtext.diagnostics.Diagnostic.Linking) 'Couldn't resolve reference to FMU 'rollbackend'.' on SpecifiedPort, offset 254, length 11 ERROR (org.eclipse.xtext.diagnostics.Diagnostic.Linking) 'Couldn't resolve reference to Port 'level'.' on SpecifiedPort, offset 266, length 5 at org.junit.Assert.fail(Assert.java:88) at org.eclipse.xtext.testing.validation.ValidationTestHelper.assertNoErrors(ValidationTestHelper.java:142) at org.eclipse.xtext.testing.validation.ValidationTestHelper.assertNoErrors(ValidationTestHelper.java:48) at be.uantwerpen.ansymo.semanticadaptation.cg.cpp.tests.CgCppBasicTest.__assertNoParseErrors(CgCppBasicTest.java:237) at be.uantwerpen.ansymo.semanticadaptation.cg.cpp.tests.CgCppBasicTest.__parseNoErrors(CgCppBasicTest.java:159) at be.uantwerpen.ansymo.semanticadaptation.cg.cpp.tests.CgCppBasicTest.rollback_test(CgCppBasicTest.java:87) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) at org.eclipse.xtext.testing.XtextRunner$1.evaluate(XtextRunner.java:49) at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) at org.junit.runners.ParentRunner.run(ParentRunner.java:363) at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:678) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192) ```
claudio commented 3 years ago
Owner

That's because the names are identifiers (and we should keep it that way). From my previous experience providing support for fmu port names that contain "@"'s, solving this bug will be a pain.

I implemented support for weird port names by adding a new field, called "alias" which is of type string.

The reason we must keep the use of identifiers is because xtext is built with a couple of assumptions about them, that allows us to allow cross referencing easily, and avoids the clash between identifiers and keywords.

As such, I ask: is this bug really important to be solved? Can we just change the name of the FMU?

That's because the names are identifiers (and we should keep it that way). From my previous experience providing support for fmu port names that contain "@"'s, solving this bug will be a pain. I implemented support for weird port names by adding a new field, called "alias" which is of type string. The reason we must keep the use of identifiers is because xtext is built with a couple of assumptions about them, that allows us to allow cross referencing easily, and avoids the clash between identifiers and keywords. As such, I ask: is this bug really important to be solved? Can we just change the name of the FMU?
casper commented 3 years ago
Collaborator

I do not think it is important to solve the bug now. But if (when) this great DSL becomes mainstream, then it will be necessary to perform either:

  1. Rename the fmu, rename it back afterwards.
  2. Support the naming

The reason for this is, that companies might have a lot of other tools in their toolchain that automatically generates stuff, imports stuff, tests stuff, and therefore depend on a giving naming.

But I agree, it is not important now.

I do not think it is important to solve the bug now. But if (when) this great DSL becomes mainstream, then it will be necessary to perform either: 1. Rename the fmu, rename it back afterwards. 2. Support the naming The reason for this is, that companies might have a lot of other tools in their toolchain that automatically generates stuff, imports stuff, tests stuff, and therefore depend on a giving naming. But I agree, it is not important now.
Sign in to join this conversation.
No Milestone
No assignee
2 Participants
Loading...
Cancel
Save
There is no content yet.