rfgi...@gmail.com
unread,Nov 14, 2013, 9:14:37 AM11/14/13You do not have permission to delete messages in this group
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
to
I believe I have a bug report, but it doesn't seem reasonable to file a new issue in JIRA. So I'm submitting it here.
Please help me understand whether this is an actual bug and if an issue should be filed for this.
------------------ 8< ------------------
Environment:
Debian GNU/Linux
Linux ********** 3.10-3-amd64 #1 SMP Debian 3.10.11-1 (2013-09-10) x86_64 GNU/Linux
java version "1.7.0_21"
OpenJDK Runtime Environment (IcedTea 2.3.9) (7u21-2.3.9-5)
OpenJDK 64-Bit Server VM (build 23.7-b01, mixed mode)
Description:
The options LOOKAHEAD and FORCE_LA_CHECK do not work together in a reasonable manner.
Consider the following simple grammar, expressed as regexp EBNF:
s = (a | b)*
a = "x" "y"
b = "x" "z"
While this grammar could be easily transformed from LL(2) to an LL(1), this is to intended to be taken as a simple example for situations that may appear in a more complex scenario.
Using a LOOKAHEAD(2) or globally setting LOOKEAHEAD=2 should ensure proper parsing of this grammar. However, this will leave the user without the assistance of Java CC to ensure their grammar is indeed LL(2).
Java CC suggests using the option FORCE_LA_CHECK. However, the usage of this option will cause Java CC to continue issuing warnings and suggesting the user to set a lookeahead of 2 or more -- even though that's what brought them to setting FORCE_LA_CHECK in the first place.
It seems that the option FORCE_LA_CHECK causes Java CC to always expect an LL(1) grammar, regardless of any LOOKAHEAD declarations.
What should be expected: when LOOKAHEAD is set to K, Java CC, at least when issued an explicit FORCE_LA_CHECK, should issue warnings only if the choice ambiguity cannot be solved with a lookeahead of K tokens.