Как написать Линтер? [закрытый]
в моей повседневной работе я и другие члены моей команды пишут много аппаратных моделей в Verilog-AMS, языке, поддерживаемом в основном коммерческими поставщиками и несколькими проектами симуляторов с открытым исходным кодом. Одна вещь, которая сделала бы поддержку кода друг друга более полезной, была бы линтером, который проверял бы наш код на наличие общих проблем и помогал бы применять общий стиль форматирования кода. Я, конечно, хочу иметь возможность добавлять свои собственные правила и после того, как я докажу их полезность для себя, продвигать их к остальная команда.. Я не против делать работу, которая должна быть сделана, но, конечно, также хочу использовать работу других существующих проектов.
наличие разрешенного синтаксиса языка в формате yacc или bison дает мне ногу? или я должен просто сосать каждый оператор языка в строку Perl и использовать подстановочные знаки, чтобы найти то, что мне не нравится?
(большинство синтаксических и компиляционных ошибок легко улавливаются коммерческими инструментами.. но у нас есть свои. расширенями.)
7 ответов
lex / flex и yacc / bison обеспечивают простой в использовании, хорошо понятный лексер-и парсер-генераторы, и я бы действительно рекомендовал сделать что-то подобное, а не делать это процедурно, например, Perl. Регулярные выражения-это мощный материал для разрыва строк с относительно-, но не полностью фиксированной структурой. С любым реальным языком программирования размер Вашей государственной машины становится просто неуправляемым с чем-либо, кроме реального лексера/парсера (tm). Представьте, что вы имеете дело со всеми возможные перестановки ключевых слов, идентификаторов, операторов, посторонних скобок, посторонних точек с запятой и комментариев, которые разрешены в чем-то вроде Verilog AMS, только с регулярными выражениями и процедурным кодом.
нельзя отрицать, что там есть существенная кривая обучения, но писать грамматику, которую вы можете использовать для flex и bison, и делать что-то полезное на синтаксическом дереве, которое выходит из bison, будет гораздо лучше использовать ваше время, чем писать тонну специальный код обработки строк, который более естественно связан с использованием синтаксического дерева в первую очередь. Кроме того, то, что вы узнаете, написав его таким образом, действительно расширит ваш набор навыков таким образом, что написание кучки хакерского кода Perl просто не будет, поэтому, если у вас есть средства, я настоятельно рекомендую его; -)
кроме того, если вы ленивы, проверьте Плагины Eclipse, которые делают подсветку синтаксиса и базовую рефакторинг для Verilog и VHDL. Они в невероятно примитивном состоянии, насколько я знаю., но у них может быть какой-то код, который вы ищете, или, по крайней мере, базовый фрагмент кода, чтобы лучше информировать ваш подход при прокатке.
Я написал пару парсеров verilog, и я бы предложил PCCTS/ANTLR, если ваш любимый язык программирования-C/C++/Java. Есть PCCTS/ANTLR грамматики на языке Verilog что вы можете начать с. Мой любимый генератор парсеров -зебу который основан на общем Lisp.
конечно большая работа, чтобы уточнить все правила пылеобразования. Имеет смысл сделать какой-то язык, чтобы определить правила пылеобразования, а также.
Не стоит недооценивать объем работы, который идет в Линтер. Разбор-это простая часть, потому что у вас есть инструменты (bison, flex, ANTLR/PCCTS) для автоматизации большей части.
но как только у вас есть разбор, то что? Необходимо построить семантическое дерево для проекта. В зависимости от того, насколько сложны ваши входы, вы должны разработать дизайн Verilog-AMS (т. е. разрешение параметров, развертывание генерирует и т. д. Если вы используете эти функции). И только тогда вы можете попытаться реализовать правила.
Я бы серьезно рассмотрел другие возможные решения, прежде чем писать Линтер, если только количество пользователей и потенциальная экономия времени не оправдывают время разработки.
пытаясь найти свой ответ, я нашел это на ANTLR - может пригодиться
Если вы используете Java вообще (и, следовательно, идею), IDE расширения для пользовательских языков можно использовать
yacc/bison наверняка дает вам ногу, поскольку хорошие пылеобразования потребует разбора программы. Regex (true regex, по крайней мере) может охватывать тривиальные случаи, но легко написать код, который regexes не соответствуют, но все еще плохой стиль.
ANTLR выглядит как альтернативный путь к более распространенному (OK Я слышал о них раньше) подход YACC/BISON, который, оказывается, также обычно использует LEX/FLEX в качестве переднего конца.
Быстрое чтение man-страницы FLEX заставляет меня думать, что это может быть основой для такого типа идеи regex..
Ok.. Я позволю этому рагу немного дольше, а затем посмотрю, как быстро я смогу построить прототип парсера в одном или другом.
и немного дольше