Hi Oleg, >> Does every "part" which is parsed during partial parsing look like a whole >> file with EOF at the end?
Yes, it does and there is no backwards compatible way to circumvent that. Same
example as from my previous answer applies to partially parsed models, e.g. if
the changed text looks like this:
ID ID ID
but the affected region would only be a nest_rule, the parial parsing would
erroneously succeed and the syntax problem would remain undetected.
Regards,
Sebastian
On 15.01.2014, at 11:58, Oleg Bolshakov wrote:
> 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
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ xtext-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/xtext-dev
