|
|
|
| Re: How to avoid ambiguity [message #1850699 is a reply to message #1850697] |
Mon, 14 March 2022 19:50   |
 Konrad Jünemann
Messages: 93
Registered: December 2018 |
Member |
|
|
Quote:
did you try to use predicate?
fragment AnnotationName * hidden () :
'@' ->name=ID?
;
I did, but it apparently did nothing - at least nothing I noticed. I still get the "the decision cannot distinguish between alternative(s)"... error when parsing the grammar. Is there any way I can debug in more detail what goes wrong?
( I tried both the -> and the => predicates, both at the AnnotationName and Item locations)
[Updated on: Mon, 14 March 2022 19:57] Report message to a moderator |
|
|
| Re: How to avoid ambiguity [message #1850700 is a reply to message #1850698] |
Mon, 14 March 2022 19:57 |
Konrad Jünemann
Messages: 93
Registered: December 2018 |
Member |
|
|
Ed Willink wrote on Mon, 14 March 2022 19:44
Are blank named annotations really such a good idea?
I don't actually want to allow blank named annotations - I just want to support them syntactically, not semantically. I wrote a validation that throws errors for blank annotations. The reason I want to allow blank annotations is that I want to propose (during content assist) which annotations are allowed at this specific item - in order to do so I need the (following) item to be parseable.
To be more specific: when the user types a '@' character content assist should already propose all valid annotations. But if the model is not syntactically correct in this state, I cannot do that (as I cannot analyze the following item).
Edit: the rule my grammar should follow is actually quite simple, I just don't know how to implement it, if it is possible at all:
- if there follows an ID directly after the '@' character (without any whitespaces), then this is the name of the annotation, no matter what characters follow.
- if there follows no ID, then the name of the annotation should be blank.
[Updated on: Mon, 14 March 2022 20:08] Report message to a moderator |
|
|
|
|
| Re: How to avoid ambiguity [message #1850704 is a reply to message #1850703] |
Mon, 14 March 2022 20:45 |
Konrad Jünemann
Messages: 93
Registered: December 2018 |
Member |
|
|
OK, the problem seems to be that the item's block brackets are optional too.
This should work (even without predicate):
Item:
{Item}(annotations+=Annotation)?
name=ID
'{'
'}'
;
Annotation:
{Annotation}
AnnotationName ( '(' ')' )?
;
fragment AnnotationName * hidden () :
'@' name=ID?
;
This should not work (with or without predicate):
Item:
{Item}(annotations+=Annotation)?
name=ID
(
'{'
'}'
)?
;
Annotation:
{Annotation}
AnnotationName ( '(' ')' )?
;
fragment AnnotationName * hidden () :
'@' ->name=ID?
;
Is there another trick I could try?
[Updated on: Mon, 14 March 2022 20:45] Report message to a moderator |
|
|
|
|
| Re: How to avoid ambiguity [message #1850740 is a reply to message #1850706] |
Tue, 15 March 2022 18:16 |
Konrad Jünemann
Messages: 93
Registered: December 2018 |
Member |
|
|
I tried to extrapolate the proposed solution to my real grammar and was unable to get it to work. Here is a fairly minimal grammar that illustrates the problem:
grammar org.xtext.example.mydsl.MyDsl with org.eclipse.xtext.common.Terminals
generate myDsl "http://www.xtext.org/example/mydsl/MyDsl"
Model:
enumerations+=Enumeration*;
Enumeration:
{Enumeration}
(annotations+=Annotation)?
name=ID
'{'
(
encodings+=Encoding ( ',' encodings+=Encoding)*
)?
'}'
;
Encoding:
Annotations
name=ID
;
fragment Annotations * :
(annotations+=Annotation)*
;
Annotation:
{Annotation}
AnnotationName ( '(' ')' )?
;
fragment AnnotationName * hidden () :
(
'@' name=ID?
)
;
Here is a couple of test cases that should all parse correctly:
MyEnumeration {
Test1,
@ABC()
Test2,
@ABC
Test3,
@ABC()
@DEF
Test4,
@
Test5,
@()
Test6,
@DEF
@
@()
@ABC()
Test7,
}
The grammar posted above throws the error:
error(202): ../org.xtext.example.mydsl/src-gen/org/xtext/example/mydsl/parser/antlr/internal/InternalMyDsl.g:356:3: the decision cannot distinguish between alternative(s) 1,2 for input such as "RULE_ID EOF EOF"
I tried to debug it with ANTLRWorks, with no success - I am probably dooing it wrong, but ANTLRworks shows no problems to me. I then tried to use predicates, following the guide here: https://www.slideshare.net/schwurbel/getting-rid-of-backtracking (written by Jan Köhnlein), but to no avail.
Maybe you guys have another hint what I could try? Or is it simply not possible to create a grammar like this (with justifiable effort)?
|
|
|
|
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.25437 seconds
] 
Search
Help
Register
Login
Home
