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

[Michael Matera]

Hi,

Sorry to nag, but my test case shows that what you have suggested is not
the problem.  During the test case execution I print out the AST that
resulted from matching the wildcard and, in both 3.1.1 and 3.2, the
resulting AST is exactly the same.  The difference in behavior is caused
by running my TreeParser on the resulting AST.  In 3.2 it seems that
more nodes magically appear when they shouldn't.

Cheers
./m


Gavin Lambert wrote:
> At 10:44 10/12/2009, Michael Matera wrote:
>>It seems that the '.' operator has become more greedy in
>>the 3.2 release.
> 
> I haven't tried 3.2 myself yet, but from what I recall of prior
> discussion on the list:
>  - in 3.0 and 3.1 the . operator was "match a single token" and did not
> consume an entire subtree.
>  - in 3.2, the . operator is supposed to be "match a single token or
> subtree".
> 
> So 3.2's . should be the equivalent of 3.0 or 3.1's "(. | ^(. .+))". 
> (Whether that's actually the case or not, I don't know.)
> 
> 
> ie. given a rule:
>   rule : ^(ROOT a=. b=. c=.) ;
> 
> under 3.0/3.1 people were reporting:
>   input = ^(ROOT ID ^(BLOCK ONE TWO) THREE)
>   a = ID
>   b = BLOCK
>   c = DOWN
> (I think.  c might have been ONE or THREE instead [I don't remember],
> but b wasn't the whole subtree.)
> 
> Under 3.2 it's supposed to do what you'd expect.  (Again, whether it
> does or not...)
> 
> 

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.