Running 'Check Realizability' analysis causes Xtext exception (and possible crash)

[kfhoech]

Running 'Check Realizability' analysis causes an IllegalStateException in Xtext errors as follows:

java.lang.IllegalStateException: The resource should have no more than one root element, but: [org.osate.aadl2.impl.AadlPackageImpl@2f336e00 (name: Top_System), org.osate.aadl2.impl.SystemImplementationImpl@2f51cb99 (name: Top_System.wrapper) (noPrototypes: false, noAnnexes: false, noProperties: false) (derivedModes: false, noFlows: false, noModes: false) (noSubcomponents: false, noConnections: false, noCalls: false)]
at org.eclipse.xtext.resource.DerivedStateAwareResource.installDerivedState(DerivedStateAwareResource.java:239)
at org.eclipse.xtext.resource.DerivedStateAwareResource.getContents(DerivedStateAwareResource.java:97)
at org.eclipse.emf.ecore.util.EcoreUtil.getAllContents(EcoreUtil.java:1178)
at org.eclipse.xtext.linking.lazy.LazyLinkingResource.resolveLazyCrossReferences(LazyLinkingResource.java:125)
at org.eclipse.xtext.EcoreUtil2.resolveLazyCrossReferences(EcoreUtil2.java:498)
at org.eclipse.xtext.ui.editor.reconciler.XtextDocumentReconcileStrategy.postParse(XtextDocumentReconcileStrategy.java:175)
at org.eclipse.xtext.ui.editor.reconciler.XtextDocumentReconcileStrategy.doReconcile(XtextDocumentReconcileStrategy.java:153)
at org.eclipse.xtext.ui.editor.reconciler.XtextDocumentReconcileStrategy.reconcile(XtextDocumentReconcileStrategy.java:67)
at org.eclipse.xtext.ui.editor.reconciler.XtextReconciler.doRun(XtextReconciler.java:449)
at org.eclipse.xtext.ui.editor.reconciler.XtextReconciler.access$3(XtextReconciler.java:429)
at org.eclipse.xtext.ui.editor.reconciler.XtextReconciler$1.process(XtextReconciler.java:363)
at org.eclipse.xtext.ui.editor.reconciler.XtextReconciler$1.process(XtextReconciler.java:1)
at org.eclipse.xtext.util.concurrent.IUnitOfWork$Void.exec(IUnitOfWork.java:37)
at org.eclipse.xtext.resource.OutdatedStateManager.exec(OutdatedStateManager.java:91)
at org.eclipse.xtext.ui.editor.model.XtextDocument$XtextDocumentLocker.modify(XtextDocument.java:428)
at org.eclipse.xtext.ui.editor.model.XtextDocument.internalModify(XtextDocument.java:162)
at org.eclipse.xtext.ui.editor.reconciler.XtextReconciler.run(XtextReconciler.java:360)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:56)

This can result in an infinite series repeated errors and essentially hang the UI because Xtext cannot complete its work.

Occurs on both Windows and Linux. (Given the nature of the error, that's expected.)

Duplicated with clean checkout of develop branch at hash 2af6b96.

[kfhoech]

The problem here seems to be that for Realizability analysis, the VerifyHandler creates an ephemeral system implementation for the selected system type and then applies the OSATE buildInstanceModelFile for the ephemeral instance. The combination of an otherwise unlinked system implementation and instantiation must violate an Xtext API rule.

This issue also affects the MATLAB codegen as it also uses the same combination of ephemeral implementation and instantiation as does Realizability.

[kfhoech]

Looks like one of two choices to solve this...

1. Build (and maintain) a parallel AGREE program builder that works on system types (rather than system instances) and further handles all of the model instantiation rules. This is a huge effort and a large maintenance burden to keep things in sync.
2. In sort of an ugly means of getting the ephemeral system implementation, we, using a transactional editing domain, generate a new package file with an unlikely name (perhaps with a GUID and then an iterating on new names until we find one that is not in use), generating in the ephemeral package file an empty system implementation of the given system type, saving the ephemeral package file, passing the generated system implementation to the remainder of the analysis (including instantiation), and then cleaning up the generated instantation file and the ephemeral package file.

Looks like the latter is the way to go...

[kfhoech]

Fixed with pull request 80. #80