#3 Cannot parse inner fmu names with hyphen

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)

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?

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.