Комментарии 9
Правильно ли я понимаю, что если идти в анализе дальше, то по сути можно дойти уже до некой виртуальной машины, которая интерпретирует входной код и ищет в процессе ошибки?
Нет ли тут аналогии с антивирусами, которые в процессе анализа вирусов дошли до интерпретации их кода, чтобы оценить его результата?
Если абстрагироваться от строгих значений терминов, то мы уже интерпретируем входной код и в процессе ищем ошибки. В конце концов, статический анализатор это буквально половинка компилятора (та, которой не надо генерировать код, так что половинка не в плане объёма), и пересекается по функционалу, собственно, с интерпретатором. Так что двигаться дальше особо и некуда - непосредственное выполнение кода это уже плоскость динамического анализа, который является отдельной дисциплиной.
В нашем случае был выбран ANTLR v4. Так как инструмент тоже написан на Java, с ним очень удобно работать. И это помимо того, что за долгие годы развития он начал справляться со своей задачей очень хорошо.
На самом деле уже не очень хорошо. Проект в стадии минимальной поддержки, т.е. крупных релизов уже не выходило несколько лет. А за это время в нем накопилось уже большое количество проблем.
По своей классификации оно, кажется, будет ближе к дереву разбора. Но, на самом деле, здесь уже можно остановиться и начать работать с ним.
Это и есть дерево разбора - ANTLR 4 генерирует именно его. Правда это дерево не очень достоверное - типы в нем не очень точные, а ошибки парсинга в нем не сохраняются.
Настроить ANTLR так, чтобы он сразу выдавал нужный AST. Звучит максимально правдоподобно, но всё ещё нужно изучать сам ANTLR, что тоже будет ощутимой тратой времени.
А чем вас не устраивает стандартный Visitor или Listener (Walker) для преобразования дерева в нужный формат? Их тоже можно генерировать с помощью ANTLR 4. С учетом того, что вы уже и так изучили ANTLR, данное дообучение по использованию Visitor выглядит минимальным.
Было бы преувеличением сказать, что ANTLR был изучен очень глубоко, поэтому со всем любопытством спрошу: а такой есть? :)
Видели, что что-то похожее было для третьей версии (в том числе поэтому и отметил вариант как максимально правдоподобный), но в разумные сроки найти что-то для четвёртого не вышло, поэтому решили сделать свою реализацию Listener-a.
Было бы преувеличением сказать, что ANTLR был изучен очень глубоко, поэтому со всем любопытством спрошу: а такой есть? :)
Конечно есть. Я сейчас заметил, что это плохо описано в официальной документации, но можно почитать здесь: https://tomassetti.me/listeners-and-visitors/ Либо просто поискать в гугле по словам antlr 4 visitor.
А, кажется, я не так понял первое сообщение, либо невнимательно прочитал материал по ссылке. Мы и наследуемся от сгенерированного BaseListener-а, тут обошлось без велосипеда. В статье указано его использование (LuaAstParser).
ParseTreeWalker walker = new ParseTreeWalker();
var listener = new LuaAstParser();
walker.walk(listener, new LuaParser(
new CommonTokenStream(lexer)
).start_());
return listener.getFile();
Единственное, сейчас увидел что можно было немного сэкономить время и не строя дерево разбора сразу построить AST.
А так я сначала подумал, что его тоже можно было сгенерировать файлом грамматики/декларативной настройкой, и об этом же пункт в статье.
И да, раз это просто экспериментальный проект, далее по тексту называть наш анализатор будем Mun.
Кажется, кто-то вдохновлялся KSP.
Применительно к Lua, проект с названием Mun уже существует. Но раз это тестовый анализатор, то это ни на что не влияет.
Как сделать анализатор кода за два дня