Class Lexer

  • All Implemented Interfaces:
    TokenSource

    public abstract class Lexer
    extends BaseRecognizer
    implements TokenSource
    A lexer is recognizer that draws input symbols from a character stream. lexer grammars result in a subclass of this object. A Lexer object uses simplified match() and error recovery mechanisms in the interest of speed.
    • Field Detail

      • input

        protected CharStream input
        Where is the lexer drawing characters from?
    • Method Detail

      • reset

        public void reset()
        Description copied from class: BaseRecognizer
        reset the parser's state; subclasses must rewinds the input stream
        Overrides:
        reset in class BaseRecognizer
      • nextToken

        public Token nextToken()
        Return a token from this source; i.e., match a token on the char stream.
        Specified by:
        nextToken in interface TokenSource
      • getEOFToken

        public Token getEOFToken()
        Returns the EOF token (default), if you need to return a custom token instead override this method.
      • skip

        public void skip()
        Instruct the lexer to skip creating a token for current lexer rule and look for another token. nextToken() knows to keep looking when a lexer rule finishes with token set to SKIP_TOKEN. Recall that if token==null at end of any token rule, it creates one for you and emits it.
      • setCharStream

        public void setCharStream​(CharStream input)
        Set the char stream and reset the lexer
      • getCharStream

        public CharStream getCharStream()
      • emit

        public void emit​(Token token)
        Currently does not support multiple emits per nextToken invocation for efficiency reasons. Subclass and override this method and nextToken (to push tokens into a list and pull from that list rather than a single variable as this implementation does).
      • emit

        public Token emit()
        The standard method called to automatically emit a token at the outermost lexical rule. The token object should point into the char buffer start..stop. If there is a text override in 'text', use that to set the token's text. Override this method to emit custom Token objects. If you are building trees, then you should also override Parser or TreeParser.getMissingSymbol().
      • matchAny

        public void matchAny()
      • getLine

        public int getLine()
      • getCharPositionInLine

        public int getCharPositionInLine()
      • getCharIndex

        public int getCharIndex()
        What is the index of the current character of lookahead?
      • getText

        public String getText()
        Return the text matched so far for the current token or any text override.
      • setText

        public void setText​(String text)
        Set the complete text of this token; it wipes any previous changes to the text.
      • reportError

        public void reportError​(RecognitionException e)
        Description copied from class: BaseRecognizer
        Report a recognition problem. This method sets errorRecovery to indicate the parser is recovering not parsing. Once in recovery mode, no errors are generated. To get out of recovery mode, the parser must successfully match a token (after a resync). So it will go: 1. error occurs 2. enter recovery mode, report error 3. consume until token found in resynch set 4. try to resume parsing 5. next match() will reset errorRecovery mode If you override, make sure to update syntaxErrors if you care about that.
        Overrides:
        reportError in class BaseRecognizer
      • getErrorMessage

        public String getErrorMessage​(RecognitionException e,
                                      String[] tokenNames)
        Description copied from class: BaseRecognizer
        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. This also makes it much easier for the exception handling because the exception classes do not have to have pointers back to this object to access utility routines and so on. Also, changing the message for an exception type would be difficult because you would have to subclassing exception, but then somehow get ANTLR to make those kinds of exception objects instead of the default. This looks weird, but trust me--it makes the most sense in terms of flexibility. For grammar debugging, you will want to override this to add more information such as the stack frame with getRuleInvocationStack(e, this.getClass().getName()) and, for no viable alts, the decision description and state etc... Override this to change the message generated for one or more exception types.
        Overrides:
        getErrorMessage in class BaseRecognizer
      • getCharErrorDisplay

        public String getCharErrorDisplay​(int c)
      • recover

        public void recover​(RecognitionException re)
        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. You can instead use the rule invocation stack to do sophisticated error recovery if you are in a fragment rule.
      • traceIn

        public void traceIn​(String ruleName,
                            int ruleIndex)
      • traceOut

        public void traceOut​(String ruleName,
                             int ruleIndex)