Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 369175

Summary:	Serializer produces results that don't conform to the grammar
Product:	[Modeling] TMF	Reporter:	Ed Merks <Ed.Merks>
Component:	Xtext	Assignee:	Project Inbox <tmf.xtext-inbox>
Status:	NEW ---	QA Contact:
Severity:	normal
Priority:	P3	CC:	costasradu01, galland, mike, moritz.eysholdt, niels.brouwers
Version:	2.3.0
Target Milestone:	---
Hardware:	PC
OS:	Windows 7
Whiteboard:

Description Ed Merks

2012-01-20 02:13:37 EST

The particular problem I have is with XReferences in Xcore

XReference:
	(annotations+=XAnnotation)*
	((resolveProxies?='resolving'? & (containment?='contains' | container?='container')) | (local?='local'? & 'refers'))

You can see from the grammar that it should not be possible to proceed without producing at least contains, container, or refers, with resolving and local being optional where the former is allowed only in the first two cases while the latter only in the last one.  The serializer ends up not producing the refers keyword for proxy resolving references.

If you install Xcore you can see this by invoking Convert to Xcore on a *.genmodel. This used to work long ago.  Then the serialize threw exceptions for quite some time.  Now it produces these wrong results.

I suppose I could change the grammar if this can't be solved...

Comment 1 Moritz Eysholdt

2012-01-20 12:42:11 EST

Hi Ed,

this is because the serializer currently treats unordered groups as multiple alternatives. I.e., for the serializer ('a' & 'b') is the same as ('a' | 'b')*.

I did this because the sate machines for muliple alternatives are easier to create and tend to be much smaller then then ones for "real" unordered groups.

What you're experiencing right now is the downside that in a multiple alternative, every element is implicitly optional.

As a workaround, you can enable the old behavior of the serializer, which is to treat unordered groups as regular groups (i.e. ('a' & 'b') equals ('a' 'b')):

You'll need to to subclass org.eclipse.xtext.serializer.analysis.ContextPDAProvider and overwrite the following method:

---
protected Pda<ISerState, RuleCall> createPDA(EObject context) {
  SerializerCfg cfg = new SerializerCfg(context);
  SerializerFollowerFunction ff = new SerializerFollowerFunction(cfg, context);
  
  // treat unordered groups as regular groups
  ff.setUnorderedStrategy(FollowerFunctionImpl.UnorderedStrategy.SEQUENCE);
  
  Pda<ISerState, RuleCall> pda = new PdaUtil().create(cfg, ff, new SerializerPDAElementFactory());
  new NfaUtil().removeOrphans(pda);
  return pda;
}
----

The downside of this workaround, however, is, that if you parse and re-serialize models the order in which unorderedgrou-elements will be serialized is determined by the grammar and *not* by the preveiously parsed files. I.e. the order doesn't remain how it was but is reseted to its default.

I'll leave this bug open until there is a real solution for this.

Comment 2 Ed Merks

2012-01-21 10:28:14 EST

Shouldn't it treat ('a' & 'b') as ('a' 'b') | ('b' 'a').  I know that the number of permutations grows exponentially (n!).  I can can work around the problem like this:

XReference:
	(annotations+=XAnnotation)*
	((resolveProxies?='resolving' containment?='contains') |
	 (containment?='contains' resolveProxies?='resolving') |
	 containment?='contains' |
	 (resolveProxies?='resolving' container?='container') |
	 (container?='container' resolveProxies?='resolving') |
	 container?='container' |
	 (local?='local' 'refers') |
	 ('refers' local?='local') |
	 'refers')

But that's just doing by hand what the serialize could do automatically.

Comment 3 Moritz Eysholdt

2012-05-09 04:44:09 EDT

once this is fixed, activate the test cases mentioned in bug 369175

Comment 4 Moritz Eysholdt

2012-05-09 04:46:00 EDT

(In reply to comment #3)
> once this is fixed, activate the test cases mentioned in bug 369175

The link was supposed to point to bug 346695

Comment 5 Moritz Eysholdt

2012-05-09 04:46:28 EDT

*** Bug 346695 has been marked as a duplicate of this bug. ***

Comment 6 Moritz Eysholdt

2015-01-08 05:55:34 EST

*** Bug 412600 has been marked as a duplicate of this bug. ***

Comment 7 Moritz Eysholdt

2015-01-08 05:58:00 EST

*** Bug 457006 has been marked as a duplicate of this bug. ***

Comment 8 Jan Koehnlein

2015-09-02 06:02:43 EDT

*** Bug 476409 has been marked as a duplicate of this bug. ***