I think that this is a result of fixing a bug, not introducing one, but I could be wrong. In any case, your body rule is picking up the remaining nodes it seems whereas prior to this it would not do so. Is that really your parse tree or your AST?
Basically your AST should have a node for each of body, failblock and always block. Something like this: ^(TEST ^(BODY ...) ^(FAILBLOCK ...) ^(ALWAYSBLOCK ...)) But you probably already have that? Perhaps you need to move the '.' matches into subrules if you already do have this tree structure. Send the result of printing your tree for this rather than the parse tree if you cannot get any further. Jim > -----Original Message----- > From: [email protected] [mailto:antlr-interest- > [email protected]] On Behalf Of Michael Matera > Sent: Wednesday, December 09, 2009 10:50 AM > To: [email protected] > Subject: [antlr-interest] Bug (difference) in ANTLR 3.2 tree matching. > > Hi, > > Today I noticed a difference in the matching behavior of the tree match > wildcard between ANTLR 3.1.1 and ANTLR 3.2. I suspect this is a bug > because I don't see anything on the release notes that would tell me > it's a feature. Here's the problem: > > I have a simple grammar with simplified try/catch/always blocks. I > have > a tree parser rule that matches those blocks and looks like this: > > testblock : ^('test' body=. failblock=. alwaysblock=.) > { > try { > exec(body); > } catch (MyProgramException e) { > exec(failblock); > } always { > exec(alwaysblock); > } > } > > When I updated to ANTLR 3.2 I began to notice that my 'fail' blocks > were > being executed no matter what (sometimes twice). When I dumped the > parse tree here's what I found: > > (test > (testbody (print "One")) > (failure (print "Two")) > (always (print "Three")) > ) null > > Since in my language a print statement can't fail what I expect to see > from this parse tree is: > > One > Three > > After upgrading to ANTLR 3.2 I see: > > One > Two > Three > Three > > For now I am working around the problem by using ANTLR 3.1.1 runtime > against my 3.2 generated code. I'm not sure that's the best thing to > do > but for now it's got me moving forward. > > Thanks for any help you can give me! ANTLR has made a huge impact in > my > work, I really love it! > > Cheers > ./m > > > This email and any attachments are intended for the sole use of the > named recipient(s) and contain(s) confidential information that may be > proprietary, privileged or copyrighted under applicable law. If you are > not the intended recipient, do not read, copy, or forward this email > message or any attachments. Delete this email message and any > attachments immediately. > > > > List: http://www.antlr.org/mailman/listinfo/antlr-interest > Unsubscribe: http://www.antlr.org/mailman/options/antlr-interest/your- > email-address List: http://www.antlr.org/mailman/listinfo/antlr-interest Unsubscribe: http://www.antlr.org/mailman/options/antlr-interest/your-email-address -- 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.
