[antlr-interest] bad generated code?

[Christian Bird]

Hi all,
I'm somewhat new to antlr, but I think I've run into a problem that
could be a bug.  If it's not, could someone help me determine what is
wrong?  I'm writing an antlr treeparser to traverse an AST created by
a parser.  I've tried to minimalize the treeparser grammar as much as
possible while still having the generated code exhibit the "bug" .

 zimport :
	#("import"
		(name ARROW complexNameList SEMI |
		"all" identifier SEMI) )
	;

complexNameList :complexName (COMMA complexName)*
	;

complexName :identifier (DOT identifier)+
	;

name :identifier
	| complexName
	;

identifier :ID
	;

The parser will never successfully take the "identifier" branch
through the "name" rule.  Instead it says "unexpected AST node: foo"
where foo is parsed by the lexer as an ID.  I looked at the java code
for name and it looks like this:

	public final void name(AST _t) throws RecognitionException {
		
		traceIn("name",_t);
		try { // debugging
			AST name_AST_in = (_t == ASTNULL) ? null : (AST)_t;
			
			try {      // for error handling
				if (_t==null) _t=ASTNULL;
				if ((_t.getType()==ID) && (_t.getType()==ARROW)) {
					identifier(_t);
					_t = _retTree;
				}
				else if ((_t.getType()==ID) && (_t.getType()==DOT)) {
					complexName(_t);
					_t = _retTree;
				}
				else {
					throw new NoViableAltException(_t);
				}
				
			}
			catch (RecognitionException ex) {
				reportError(ex);
				if (_t!=null) {_t = _t.getNextSibling();}
			}
			_retTree = _t;
		} finally { // debugging
			traceOut("name",_t);
		}
	}

This seems wrong.  I'm looking at the if branch for calling the
identifier rule and it looks like:

if ((_t.getType()==ID) && (_t.getType()==ARROW)) {
    identifier(_t);
    _t = _retTree;


How can the test in the if ever evaluate to true?  I see that ARROW is
in the follow-set for identifier so it seems to me that the code
should test the type of _t's SIBLING against ARROW, but not _t itself.
 Anyone every run into something like this?  Does it seem like a bug? 
Can anyone suggest a workaround?  Thanks!

I'm using antlr 2.7.5 and java 1.5.  I can attach all of the code if
needed, but this is a treeparser that extends another treeparser that
parses a tree created by a parser that gets it's tokens from a lexer. 
That's four different (and not short) files.  I appreciate any help!

-- Chris

--
Christian Bird