有没有办法轻松调整ANTLR4的错误信息？

Question

Currenlty我的工作我自己的语法，我想对特定的错误消息NoViableAlternative，InputMismatch，UnwantedToken，MissingToken和LexerNoViableAltException。

我已经扩展Lexer.class并覆盖了notifyListeners将默认错误消息更改token recognition error at:为我自己的错误消息。同样，我扩展DefaultErrorStrategy并覆盖了所有报告方法，例如reportNoViableAlternative, reportInputMismatch, reportUnwantedToken, reportMissingToken。

所有这些的目的是更改消息，这些消息将传递给syntaxError()listener的方法ANTLRErrorListener。

这是扩展的一个小例子Lexer.class：

    @Override
    public void notifyListeners(LexerNoViableAltException lexerNoViableAltException) {
        String text = this._input.getText(Interval.of(this._tokenStartCharIndex, this._input.index()));
        String msg = "Operator " + this.getErrorDisplay(text) + " is unkown.";
        ANTLRErrorListener listener = this.getErrorListenerDispatch();
        listener.syntaxError(this, null, this._tokenStartLine, this._tokenStartCharPositionInLine, msg,
            lexerNoViableAltException);
    }

或者对于DefaultErrorStrategy：

    @Override
    protected void reportNoViableAlternative(Parser recognizer, NoViableAltException noViableAltException) {
        TokenStream tokens = recognizer.getInputStream();
        String input;
        if (tokens != null) {
            if (noViableAltException.getStartToken().getType() == -1) {
                input = "<EOF>";
            } else {
                input = tokens.getText(noViableAltException.getStartToken(), noViableAltException.getOffendingToken());
            }
        } else {
            input = "<unknown input>";
        }

        String msg = "Invalid operation " + input + ".";
        recognizer.notifyErrorListeners(noViableAltException.getOffendingToken(), msg, noViableAltException);
    }

所以我读了这个线程处理 ANTLR4 中的错误， 并想知道在定制方面是否有更简单的解决方案？

Answer 1

我改进 ANTLR4 错误消息的策略有点不同。我syntaxError在我的错误侦听器中使用了一个覆盖（我有一个用于词法分析器和解析器）。通过使用给定的值和其他一些东西，例如 LL1Analyzer，您可以创建非常精确的错误消息。该词法错误监听器的处理是非常简单的（希望C ++代码是可以理解你）：

void LexerErrorListener::syntaxError(Recognizer *recognizer, Token *, size_t line,
                                     size_t charPositionInLine, const std::string &, std::exception_ptr ep) {
  // The passed in string is the ANTLR generated error message which we want to improve here.
  // The token reference is always null in a lexer error.
  std::string message;
  try {
    std::rethrow_exception(ep);
  } catch (LexerNoViableAltException &) {
    Lexer *lexer = dynamic_cast<Lexer *>(recognizer);
    CharStream *input = lexer->getInputStream();
    std::string text = lexer->getErrorDisplay(input->getText(misc::Interval(lexer->tokenStartCharIndex, input->index())));
    if (text.empty())
      text = " "; // Should never happen.

    switch (text[0]) {
      case '/':
        message = "Unfinished multiline comment";
        break;
      case '"':
        message = "Unfinished double quoted string literal";
        break;
      case '\'':
        message = "Unfinished single quoted string literal";
        break;
      case '`':
        message = "Unfinished back tick quoted string literal";
        break;

      default:
        // Hex or bin string?
        if (text.size() > 1 && text[1] == '\'' && (text[0] == 'x' || text[0] == 'b')) {
          message = std::string("Unfinished ") + (text[0] == 'x' ? "hex" : "binary") + " string literal";
          break;
        }

        // Something else the lexer couldn't make sense of (likely there is no rule that accepts this input).
        message = "\"" + text + "\" is no valid input at all";
        break;
    }
    owner->addError(message, 0, lexer->tokenStartCharIndex, line, charPositionInLine,
                    input->index() - lexer->tokenStartCharIndex);
  }
}

这段代码表明我们根本不使用原始消息，而是检查令牌文本以查看有什么问题。这里我们主要处理未闭合的字符串：

该分析器错误监听器是更为复杂，太大，张贴在这里。它是不同来源的组合来构建实际的错误消息：

• Parser.getExpectedTokens()：使用 LL1Analyzer 从 ATN 中的给定位置（所谓的后续集）获取下一个可能的词法分析器标记。然而，它查看谓词，这可能是一个问题（如果你使用这样的）。

• 标识符和关键字：在特定情况下，通常允许某些关键字作为正常标识符，这会创建带有实际用作标识符的关键字列表的后续集，因此需要额外检查以避免将它们显示为预期值：

• 解析器规则调用堆栈，在调用错误侦听器期间，解析器具有当前的解析器规则上下文 ( Parser.getRuleContext())，您可以使用它来遍历调用堆栈，以查找为您提供错误位置更具体信息的规则上下文（例如，从*匹配到假设expr规则告诉您实际上此时需要一个表达式）。

• 给定的异常：如果这是 null，则错误是关于缺少或不需要的单个令牌，这很容易处理。如果异常具有值，您可以检查它以获取更多详细信息。这里值得一提的是，异常的内容没有被使用（而且非常稀疏），而是我们使用之前收集的值。最常见的异常类型是NoViableAltand InputMismatch，当错误位置为 EOF 或类似“输入在此位置无效”时，您都可以将其转换为“输入不完整”。然后，两者都可以通过从上面提到的（并在图像中显示）规则调用堆栈和/或后续集构建的期望来增强。