Community
Participate
Working Groups
There seems to be some bug in the Xtend grammar definition that leads to wrong validation results about Real literals. The following piece of code works: Real works(): 0.10; This part doesn't: Real worksNot(): 0.01; 0.0'1' <- Every number after the second 0 is considered: extraneous input '1' expecting ';' Here's a part of the stack trace of the exception which is thrown internally and "swallowed" by Xtend: MismatchedTokenException(5!=19) at org.antlr.runtime.BaseRecognizer.mismatch(BaseRecognizer.java:117) at org.antlr.runtime.BaseRecognizer.match(BaseRecognizer.java:99) at org.eclipse.internal.xtend.xtend.parser.XtendParser.extension(XtendParser.java:1017) at org.eclipse.internal.xtend.xtend.parser.XtendLocationAddingParser.extension(XtendLocationAddingParser.java:46) at org.eclipse.internal.xtend.xtend.parser.XtendParser.file(XtendParser.java:200) at org.eclipse.internal.xtend.xtend.parser.XtendLocationAddingParser.file(XtendLocationAddingParser.java:211) at org.eclipse.internal.xtend.xtend.parser.ParseFacade.file(ParseFacade.java:70) at org.eclipse.internal.xtend.xtend.parser.ParseFacade.file(ParseFacade.java:55) at org.eclipse.internal.xtend.xtend.parser.ParseFacade.file(ParseFacade.java:50) at org.eclipse.internal.xtend.xtend.XtendResourceParser.parse(XtendResourceParser.java:25) at org.eclipse.xtend.expression.ResourceManagerDefaultImpl.loadResource(ResourceManagerDefaultImpl.java:70) at org.eclipse.xtend.expression.ExecutionContextImpl.internalAllExtensions(ExecutionContextImpl.java:326) at org.eclipse.xtend.expression.ExecutionContextImpl.access$0(ExecutionContextImpl.java:310) at org.eclipse.xtend.expression.ExecutionContextImpl$1.createNew(ExecutionContextImpl.java:347) at org.eclipse.xtend.expression.ExecutionContextImpl$1.createNew(ExecutionContextImpl.java:1) at org.eclipse.internal.xtend.util.Cache.get(Cache.java:26) at org.eclipse.xtend.expression.ExecutionContextImpl.getExtensionForTypes(ExecutionContextImpl.java:352) at org.eclipse.xtend.expression.ExecutionContextImpl.getExtension(ExecutionContextImpl.java:361) at org.eclipse.internal.xtend.expression.ast.OperationCall.evaluateInternal(OperationCall.java:72) at org.eclipse.internal.xtend.expression.ast.Expression.evaluate(Expression.java:50) at org.eclipse.xtend.expression.ExpressionFacade.evaluate(ExpressionFacade.java:56) at org.eclipse.xtend.expression.ExpressionFacade.evaluate(ExpressionFacade.java:45) at org.eclipse.xtend.XtendComponent.invokeInternal2(XtendComponent.java:190) at org.eclipse.xtend.expression.AbstractExpressionsUsingWorkflowComponent.invokeInternal(AbstractExpressionsUsingWorkflowComponent.java:239) at org.eclipse.emf.mwe.core.lib.AbstractWorkflowComponent.invoke(AbstractWorkflowComponent.java:126) at org.eclipse.emf.mwe.core.container.CompositeComponent.internalInvoke(CompositeComponent.java:104) at org.eclipse.emf.mwe.core.container.CompositeComponent.invoke(CompositeComponent.java:89) at org.eclipse.emf.mwe.core.container.ConditionalComponent.internalInvoke(ConditionalComponent.java:57) at org.eclipse.emf.mwe.core.container.ConditionalComponent.invoke(ConditionalComponent.java:39) at org.eclipse.emf.mwe.core.container.CompositeComponent.internalInvoke(CompositeComponent.java:104) at org.eclipse.emf.mwe.core.container.CompositeComponent.invoke(CompositeComponent.java:89) at org.eclipse.emf.mwe.core.container.ConditionalComponent.internalInvoke(ConditionalComponent.java:57) at org.eclipse.emf.mwe.core.container.ConditionalComponent.invoke(ConditionalComponent.java:39) at org.eclipse.emf.mwe.core.container.CompositeComponent.internalInvoke(CompositeComponent.java:104) at org.eclipse.emf.mwe.core.container.CompositeComponent.invoke(CompositeComponent.java:89) at org.eclipse.emf.mwe.core.WorkflowRunner.executeWorkflow(WorkflowRunner.java:408)
Created attachment 202033 [details] Reproducing Xpand Project
The Lexer rule "IntValue" accepts only a single "0" or "1..9" followed by other digits. IntLiteral : ('0' | '1'..'9' '0'..'9'*) ; I think the reason was that no integer values with leading zeros should be allowed. ================================================================ numberLiteral returns [Expression e] : a=IntLiteral {$e=factory.createIntegerLiteral(id(a));} | a=IntLiteral b='.' c=IntLiteral {$e=factory.createRealLiteral(id(a).append(id(b)).append(id(c)));} ; ================================================================ Changing the IntValue to IntLiteral : '0'..'9'+ ; would solve the issue, but also allow leading zeros.
I think leading zeros are ok and they won't break existing templates.
Sebastian, thanks for your input. I also think this is reasonable, but wanted a second thought. I'll fix that now.
Thanks from my side, too - nice work
Changed the definition of IntLiteral in Xpand.g and Xtend.g. In Xpand.g I had to comment out -------------------------------------------- fragment VOCAB : ('\3'..'\u00aa'|'\u00ac'..'\u00ba'|'\u00bc'..'\ufffe') ; -------------------------------------------- AntlWorks refused to generate the parser with the error message: Xpand.g:469:3: syntax error: antlr: Xpand.g:469:3: unexpected token: '\3' Added unit tests: - StatementParserTest#testReal - ExtensionParserTest#testReal
Bug resolved before Xpand 1.2 release date => Closing
