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

[Mike Matera]

[NOTE: This is a resend of my first test case with a smaller attachment, 
sorry to the moderator for sending big files :-)]

Hi Jim and Gavin,

I've created a simple test case that demonstrates the change in
behavior.  The test case shows a little bit more complicated behavior
than I originally thought.  Here's how the test case works:

I have a simple grammar + tree parser that has a try/catch block and a
simple statement.  The tree parser has a rule that matches a tree with
subtrees like this:

trycatch : ^('try' t=. c=. a=.)
    {
      run($t);
      ...
    }
    ;

The run() function in the tree parser creates another instance of the
same tree parser with the same TokenStream then runs a rule on the given
subtree.  The following are my observations from the test case.

In both versions of ANTLR when I print the contents of the subtree
(using $t.toTreeString()) the results are identical.  However the
consequence of executing the subtrees are different with execution of
subtree $t also causing the execution of subtrees $c and $a.  Please see
the test case for a demonstration of this behavior.

About the test case:

I have attached at tar.gz of my test case.  It contains the *.g files
for my grammar, a simple class with a main() routine, an input file and
the two ANTLR jars.  I develop on Linux so my test case is Linux centric
(sorry to you Windows folks).  Here's how to run the test case:

tar -zxvf AntlrTest.tar.gz
cd AntlrTest
make

The Makefile expects you to have java and javac in your path.  Also the 
Makefile downloads two versions of ANTLR from antlr.org using wget.  The 
Makefile builds two versions of the same program and executes them both. 
  Please take a minute to look over my test case, I think it shows an 
important difference between versions.


Thank you all!
./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.

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: testrun.out
Url: http://www.antlr.org/pipermail/antlr-interest/attachments/20091211/22769a94/attachment.pl 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: AntlrTest.tar.gz
Type: application/x-gzip
Size: 1639 bytes
Desc: not available
Url : http://www.antlr.org/pipermail/antlr-interest/attachments/20091211/22769a94/attachment.gz