[antlr-interest] Bug (difference) in ANTLR 3.2 tree matching.

[Michael Matera]

Hi Jim,

Thanks for the response.  Here's what my parser rules look like:

test_stmt
  : 'test' statement* fail_block always_block 'endtest'
    -> ^('test' ^(BLOCK["testbody"] statement*) fail_block always_block)
  ;

fail_block
  : 'on' 'failure' (statement*) 'end'
    -> ^(BLOCK["on failure"] statement*)
  ;

always_block
  : 'always' (statement*) 'end'
    -> ^(BLOCK["always"] statement*)
  ;

As you can see my subparts are already in separate rules.  To answer
your question it is my AST (not parse tree) as printed by:

System.out.println(((Tree) tree.getTree()).toStringTree());

When you print a tree that way it doesn't put the '^' into the output,
so the AST is actually:

^(test ^(body) ^(failblock) ^(alwaysblock))

as you have suggested.  It seems that the '.' operator has become more
greedy in the 3.2 release.  My observation of the behavior is:

Given:

^('test' a=. b=. c=.)

In 3.1.1:

a = a
b = b
c = c

In 3.2

a = a b c
b = b c
c = c

This makes some sense being that the wildcard is wild, however the
behavior that I've come to count on is that the '.' operator matches one
subtree (not a family of subtrees).

Thanks again for taking a look at this!
./m



Jim Idle wrote:
> 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: antlr-interest-bounces at antlr.org [mailto:antlr-interest-
>> bounces at antlr.org] On Behalf Of Michael Matera
>> Sent: Wednesday, December 09, 2009 10:50 AM
>> To: antlr-interest at antlr.org
>> 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
> 

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.