Sebastien, nevertheless it seems to be a bug of Xtext
I tried to simplify the generated grammar and I got this one
grammar InternalMyDsl2;
entryRuleModel:
model
EOF
;
// rule 1
model: translation_unit;
entryRuletranslation_unit:
translation_unit
EOF
;
// rule 2
translation_unit: (declaration ';')*;
entryRulenest_rule :
nest_rule
EOF
;
// rule 3
nest_rule: ID?;
entryRuledeclaration:
declaration
EOF
;
// rule 4
declaration: 'decl' nest_rule ID;
fragment LETTER : ('$'|'A'..'Z'|'a'..'z'|'_');
ID : LETTER (LETTER|'0'..'9')*;
WS : (' '|'\t'|'\r'|'\n')+;
ANY_OTHER : .;
when checking it in antlr (I currently use antlr3.5 but as we know the same
is in antlr3.2) I still have this error:
error(202): InternalMyDsl2.g:27:2: the decision cannot distinguish between
alter native(s) 1,2 for input such as "ID EOF EOF"
If I remove or comment using of "EOF" token inside the GENERATED RULE
entryRulenest_rule - NO MISTAKE anymore.
So I still didn't understand - why generate entry rules with EOF token for
EACH user xtext rule? Does every "part" which is parsed during partial
parsing look like a whole file with EOF at the end?
On 15 January 2014 02:07, Sebastian Zarnekow
<[email protected]>wrote:
> Hi Oleg,
>
> the EOF is necessary to detect superfluous tokens at the end of the
> document, e.g. a file with a grammar like this:
>
> Model:
> name = ID;
>
> is invalid if it has this content:
>
> Foo Bar Zonk
>
> Such error would remain undetected. Same applies for partial parsing, too.
> When you edit a file, Xtext will usually not reparse the complete file but
> only a necessary part of it (depending on the grammar and the amount of
> changes). The entry rules allow to do this.
>
> You are right, I was tricked by the Antlr works bug. Nevertheless, the
> grammar looks valid to me and should not produce an error in Antlr. So the
> only valid solution is to refactor it in a way that allow to parse your
> files without that pattern.
>
> Best regards,
> Sebastian
>
>
>
> On 14.01.2014, at 13:50, Oleg Bolshakov wrote:
>
> Hello, Sebastian.
>
> > entryRules describe a complete document from the beginning to the end.
> Therefore the EOF token is used in these rules.
> But is it normal that entryRules were generated for each of my Xtext
> parser rules?
>
> > They serve as parser rules if partial parsing is applied during editing
> of a file.
> why?.. What problem does "EOF" in entry rules solve in the case of partial
> parsing?
>
> >In your particular example it seems to be a bug in Antlr, e.g. if I
> manually edit the generated grammar and put meaningless parentheses
> > around the the subrule for id1 = ID?, I don't the the error anymore.
> Could you please send my this grammar? Because when I try to put
> meaningless parentheses around lv_id1_1_0=RULE_ID nothing happens (and
> especially if I put them for Xtext grammar id1 = ID?). I do it with
> antlr.3.2 in command line mode. Because I have seen some very strange
> problem with antlrWorks (a gui for antlr): when I open the program and
> check the grammar for the first time it shows THE error ("bla bla RULE_ID
> EOF EOF"), but when I click it once again it never shows that and it seems
> to be a bug! Maybe you worked in AntlrWorks and you didn't get the error
> for the second time just because it just never shows up in this case?... I
> will write to antlr support as soon as I got to know your workflow in which
> you managed to avoid the error.
>
>
>
>
>
> On 14 January 2014 12:28, Sebastian Zarnekow <[email protected]
> > wrote:
>
>> Hi Oleg,
>>
>> entryRules describe a complete document from the beginning to the end.
>> Therefore the EOF token is used in these rules.
>> They serve as parser rules if partial parsing is applied during editing
>> of a file.
>>
>> In your particular example it seems to be a bug in Antlr, e.g. if I
>> manually edit the generated grammar and put meaningless parentheses around
>> the the subrule for id1 = ID?, I don't the the error anymore.
>> I'm afraid you have to refactor your grammar slightly to adopt to that
>> issue.
>> I'd also recommend to use Java-conventional names for the production
>> rules, e.g. TranlationUnit instead of translation_unit as there will be
>> Java classes created from those names.
>>
>> Regards,
>> Sebastian
>>
>>
>> On 14.01.2014, at 09:12, Oleg Bolshakov wrote:
>>
>> Hello, I posted the message on the forum
>> http://www.eclipse.org/forums/index.php/t/636966/
>>
>> The problem seems to be somehow connected to the extensive use of "EOF"
>> tokens in generated antlr grammar though I can not understand why it's
>> done. Are there any info on what "entry rules" in generated grammar mean
>> and why EOF at the end of them is needed?
>> _______________________________________________
>> xtext-dev mailing list
>> [email protected]
>> https://dev.eclipse.org/mailman/listinfo/xtext-dev
>>
>>
>>
>> _______________________________________________
>> xtext-dev mailing list
>> [email protected]
>> https://dev.eclipse.org/mailman/listinfo/xtext-dev
>>
>>
> _______________________________________________
> xtext-dev mailing list
> [email protected]
> https://dev.eclipse.org/mailman/listinfo/xtext-dev
>
>
>
> _______________________________________________
> xtext-dev mailing list
> [email protected]
> https://dev.eclipse.org/mailman/listinfo/xtext-dev
>
>
_______________________________________________
xtext-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/xtext-dev
