Create a new node from an existing node does nothing for BaseTree
as there are no fields other than the children list, which cannot
be copied as the children are not considered part of this node.
A stripped-down version of org.antlr.misc.BitSet that is just
good enough to handle runtime requirements such as FOLLOW sets
for automatic error recovery.
BitSet() -
Constructor for class org.antlr.runtime.BitSet
A blank listener that does nothing; useful for real classes so
they don't have to have lots of blank methods and are less
sensitive to updates to debug interface.
When walking ahead with cyclic DFA or for syntactic predicates,
we need to record the state of the input stream (char index,
line, etc...) so that we can rewind the state after scanning ahead.
The most common stream of tokens where every token is buffered up
and tokens are filtered for a certain channel (the parser will only
see these tokens).
A proxy debug event listener that forwards events over a socket to
a debugger (or any other listener) using a simple text-based protocol;
one event per line.
What index is this node in the child list? Range: 0..n-1
If your node type doesn't handle this, it's ok but the tree rewrites
in tree parsers need this functionality.
What error message should be generated for the various
exception types?
Not very object-oriented code, but I like having all error message
generation within one method rather than spread among all of the
exception classes.
From what character stream was this token created? You don't have to
implement but it's nice to know where a Token comes from if you have
include files etc...
Where are you getting symbols from? Normally, implementations will
pass the buck all the way to the lexer who can ask its input stream
for the file name or whatever.
How should a token be displayed in an error message? The default
is to display just the text, but during development you might
want to have a lot of information spit out.
The most common stream of tokens is one where every token is buffered up
and tokens are prefiltered for a certain channel (the parser will only
see these tokens and cannot change the filter channel number during the
parse).
A list of CharStreamState objects that tracks the stream state
values line, charPositionInLine, and p that can change as you
move through the input stream.
Given a pattern like (ASSIGN %lhs:ID %rhs:.) with optional labels
on the various nodes and '.' (dot) as the node/subtree wildcard,
return true if the pattern matches and fill the labels Map with
the labels pointing at the appropriate nodes.
Lexers can normally match any char in it's vocabulary after matching
a token, so do the easy thing and just kill a character and hope
it all works out.
After an arbitrairly long lookahead as with a cyclic DFA (or with
any backtrack), this informs the debugger that stream should be
rewound to the position associated with marker.
Where are the bounds in the input token stream for this node and
all children? Each rule that creates AST nodes will call this
method right before returning.
A source of tokens must provide a sequence of tokens via nextToken()
and also must reveal it's source of characters; CommonToken's text is
computed from a CharStream; it only store indices into the char stream.
Because the user is not required to use a token with an index stored
in it, we must provide a means for two token objects themselves to
indicate the start/end location.
Cut-n-paste from material I'm not using in the book anymore (edit later
to make sense):
Now, how are we going to test these tree patterns against every
subtree in our original tree? In what order should we visit nodes?
For this application, it turns out we need a simple ``apply once''
rule application strategy and a ``down then up'' tree traversal
strategy.