Thank you for answering me, Jim.
In fact, the original rule seems to work well (as unit tests succeed). It is
only when I use ANTLRWorks for debugging that I encounter this exception.
I'm working with SQL2 grammar written by Lubos Vnuk. My goal is to migrate it
from v2 to v3.1.3.
The rule in question is <value_exp_primary> :
value_exp_primary :
set_fct_spec
| case_exp
| cast_spec
| {input.LA(1) == INTRODUCER}? ((column_ref)=>column_ref |
unsigned_value_spec)
| {input.LA(1) != INTRODUCER}? column_ref
| (LEFT_PAREN value_exp RIGHT_PAREN)=> LEFT_PAREN value_exp RIGHT_PAREN
| scalar_subquery
;
Yes, Lubos Vnuk wrote this to disambiguate his grammar.
The java.lang.NumberFormatException occurs when I launch this test :
select*from a where a = substring ( 'abcdefgh' || 'ijkl' from 5-2 for 1*2);
It does not matter that ANTLRWorks could not handle this input. My true problem
is that my lexer is not able to recognize 'abcdefgh' and 'ijkl', because of
quotes... But it's not the same story :-)
--
Jonathan Bayle
Stagiaire IUT Informatique Vannes
MGDIS - Département Etudes et Développement
________________________________
De : [email protected] [mailto:[email protected]]
De la part de Jim Idle
Envoyé : mercredi 12 août 2009 16:06
Cc : [email protected]
Objet : Re: [antlr-interest] Exception while debugging C# 2.0with
ANTLRWorks1.2.3
Bayle Jonathan wrote:
Hi everybody,
I have identified which piece of code returns « False » (and sometimes « True
») and make ANTLRWorks throw a "java.lang.NumberFormatException".
It is the result of 2 semantic predicates embedded in the same rule :
// beginning of rule (...)
| {input.LA(1) == MY_TOKEN}? // (...) First production
| {input.LA(1) != MY_TOKEN}? // (...) Second production
// (...) end of rule
;
I am used to work with ANTLR 2.7.7, so this syntax may be wrong under ANTLR
3.1.3.
Could anybody help me please ?
ON the face of it, it looks like yuo can just remove the predicates and 3.1
will work it out correctly. However you need to post the rule in question or we
are just guessing. Another possibility is that you want gated predicates and
just need that on the first production:
rule
: {input.LA(1) == MY_TOKEN}?=> ....
| // second rpodcution
;
The only advantage to that though would be to prevent some kind of warning so I
can't see that you need that.
Yet another possibility is that your predicates are just not correct, so, post
the actual rule in error :-)
Jim
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"il-antlr-interest" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/il-antlr-interest?hl=en
-~----------~----~----~----~------~----~------~--~---
List: http://www.antlr.org/mailman/listinfo/antlr-interest
Unsubscribe:
http://www.antlr.org/mailman/options/antlr-interest/your-email-address
