Closed steve-hickman-epistimis closed 1 year ago
@steve-hickman-epistimis Thank you for the detailed report!
In Face-types.langium, the type is defined using the value types as alternatives. At best, this seems like duplication.
Maybe it was a copy-paste error, but I can't find UopClientServerRole
in Face-types.langium
This parser rule does not create an object. Add a primitive return type or an action to the start of the rule to force object instantiation.langium
This is a known bug in Langium validation. Should be fixed soon.
A type 'UoPClientServerRole' is not expected in a rule that returns type 'UoPClientServerRole'.
This is also a Langium TypeSystem issue.
I will keep this issue open to verify errors are fixed after the upcoming release.
Maybe it was a copy-paste error, but I can't find UopClientServerRole in Face-types.langium
Very observant. I'm looking at the just regenerated file - it's not there. I wonder why that particular enum was not duplicated? Is there something unique about it being the first enum in the XText grammar?
Validation issues mentioned here are no longer reported in the current 2.0.1 Langium release
I can't reproduce your issue with the current state of your project when generating the FACE language. Also I can not access https://github.com/Epistimis/Privacy
repository.
It appears that the current version of xtext2langium no longer generates the '
@steve-hickman-epistimis
The initial idea was to generate -types.langium
if one explicitly uses a predefined metamodel (e.g. xcore). In your case, where you are using generated EMF, it is not needed as types can be inferred by the Langium framework.
I have several XText grammars with dependencies as follows:
When I generate from the Privacy grammar, I get the following files:
Face.xtext
contains the following:Face.langium
contains:Face-types.langium
containsNote the duplicated type definitions for the enums. In
Face.langium
, the type is defined using the literal string values as alternatives. InFace-types.langium
, the type is defined using the value types as alternatives. At best, this seems like duplication. It could also be the cause of the following errors (this example from theUopClientServerRole
rule inFace.langium
):Note that I can't add a return type defined in
Face-types.langium
toFace.langium
without importingFace-types.langium
intoFace.langium
. Doing that will transitively importUddl-types.langium
intoFace.langium
which results in the problem described in issue #3