From be583d9655494cc19534a0fd7080ccc60cd4cb75 Mon Sep 17 00:00:00 2001
From: Adam Wardynski <award@.(win7-laptop)>
Date: Sun, 28 Nov 2010 20:31:12 +0100
Subject: [PATCH] Ignore ambiguity warning in ML_COMMENT. It works OK This is
how they do it on the web, really. It works as expected and matches any
flavor of newline (Win, Unix, Mac) despite the ambiguity that "\n\r" can be
matched by two subrules, in the end it will be properly matched just by one
rule. Also, grammar can be k=2 for lexer.
---
libwccl/parser/grammar.g | 18 +++++++++++++-----
1 file changed, 13 insertions(+), 5 deletions(-)
diff --git a/libwccl/parser/grammar.g b/libwccl/parser/grammar.g
index cfca8cf..e0af47a 100644
--- a/libwccl/parser/grammar.g
+++ b/libwccl/parser/grammar.g
@@ -911,7 +911,7 @@ options {
exportVocab = ANTLRExpr;
charVocabulary = '\3'..'\377';
testLiterals = false;
- k = 3;
+ k = 2;
}
STRING
@@ -1075,10 +1075,18 @@ options {
paraphrase = "Multi line comment";
}
: "/*"
- ({ LA(2)!='/' }? '*'
- | ('\r' '\n') => '\r' '\n' {newline();}
- | '\r' {newline();}
- | '\n' {newline();}
+ ( /* This actually works OK despite the ambiguity that
+ '\r' '\n' can be matched in one alternative or by matching
+ '\r' in one iteration and '\n' in another.. But
+ this is really matched just by one rule per (...)*
+ loop iteration, so it's OK.
+ This is exactly how they do it all over the web - just
+ turn off the warning for this particular token.*/
+ options { generateAmbigWarnings=false; }
+ : { LA(2)!='/' }? '*'
+ | '\r' '\n' { newline(); }
+ | '\r' { newline(); }
+ | '\n' { newline(); }
| ~('*'|'\n'|'\r')
)*
"*/"
--
GitLab