lead-tools / bsparser Goto Github PK

Многие части парсера можно существенно ускорить в ущерб читабельности исходника.

Сейчас подписки вызываются по окончании обхода узла обобщенным визитером. Это позволит предоставить полезную информацию (например, статистику по подчиненным узлам) обработчику подписки, но не всегда удобно, так как подписки плагина в этом случае вызываются в обратном порядке обхода дерева (снизу вверх).

Вот такая конструкция вызывает ошибку

#Если Клиент Тогда
ИначеЕсли КакоеТоУсловие Тогда

При трансляции нужно по возможности сохранять исходное форматирование опираясь на эту информацию

Срабатывает через раз зараза

Сделать загрузку метаданных из XML конфигурации.

• проверять что все локальные переменные объявлены
• проверять что объявленные используются
• запретить прямое присваивание глобальным переменным:
  для присваивания глобальной переменной нужно выделять процедуру, которой передавать глобал параметром, и присваивать уже этому параметру внутри процедуры

Парсить по аналогии с обычным If Then. Все возможности это не покроет, но при нормальном стиле кодинга 99.99% будет разбираться без ошибок. Оставшиеся ошибки разбора пусть будут сигналом переписать это дерьмо (любая интерпретация фразы верна)

Для единообразия надо бы переименовать:
Selector -> SelectExpr
SelectorKinds -> SelectKinds

Строки вида:

1. "part1" "part2"
2. "part1
   |part2"

хранить в AST как выражение, в котором части строки соединяются через виртуальную операцию переноса строки.

Возможна ситуация, когда в одном модуле объявлены переменные с одинаковыми именами:

&AtClient
Var Name;

&AtServer
Var Name;

Сейчас парсер ругается на повторное объявление

Дописать в VisitDesigExpr и VisitTernaryExpr обход селекторов.

Признак Export перенести в Object
Узлы VarDecl и ParamDecl упразднить

В первую очередь в целях автоматического тестирования парсера

• Выдавать ошибку разбора если в числовом литерале более одной точки (сейчас исключение преобразования в число)
• Выдавать ошибку разбора если в объявлении локальной переменной указан Export (сейчас тихий игнор)
• Запретить обращение к переменной в правой части присваивания, если эта переменная создается в левой части (создавать переменную после разбора выражения)
• Циклы For и For Each должны создавать авто-переменные после разбора выражений
• Если до методов в модуле есть регион, то переменная сразу за ним будет ошибкой разбора
• Обращение по индексу может содержать только одно выражение (сейчас список)
• Для первого варианта New нужно выделить отдельную сущность под конструктор (сейчас берется переменная или функция из текущего скопа)
• Выражения препроцессора должны разбираться в рамках отдельного фиктивного скопа
• Выражения препроцессора могут быть только логическими (сейчас парсер пропускает любые)
• Проверять что директивы и инструкции препроцессора являются правильными идентификаторами (сейчас исключение в Property())

• программный интерфейс
• виды плагинов
• документация

• Все узлы должны корректно транслироваться
• Восстанавливать форматирование насколько это возможно
• Тип узлов проверять только через перечисление Nodes

• Добавить программный интерфейс плагина
• Добавить комментарии на русском к объектам, выводимым в документацию

http://docs.yworks.com/yfiles/doc/developers-guide/graphml.html
Не знаю что из этого выйдет. Но покрутить граф в Yed должно быть прикольно 😄

Надо таки наверно вернуться к этой заготовке и добить ее 😄
Уже в самом начале стало понятно, что идея с Goto была плохой. Проблема в возвратах из процедур - для них придется городить большой If, в котором будут все возможные места возврата. Вариант рабочий, но дюже некрасивый. Потому я на него забил.
Вызов процедур лучше организовать на состояниях в цикле по аналогии с машиной Тьюринга.

Хз зачем, но сделать не сложно. Будет пруф оф концепт

• сделать общий конструктор узлов AST (для автодоков)
• сделать разбор выражений однообразным (операции в массивах)
• выделить субрегионы ParseExpr, ParseDecl, etc в регионе Parser
• все узлы (кроме элементов скопа) должны иметь информацию о положении в исходном коде
• информацию о положении в исходном коде хранить в узлах в одном поле-структуре "Place"
• названия полей в узлах заменить по возможности на более лаконичные
• состав полей узлов должен быть фиксированным
• описание типов полей в комментариях должно быть формальным (для автодоков)
• упразднить узел Object (просто лишняя сущность)
• Вместо Variable сделать два вида объектов: VarMod и VarLoc
• добавить ключевое слово Null
• добавить тип узла ElsIf
• для Parser, Scanner, etc сделать общий конструктор Class (для автодоков)
• сделать обобщенный визитер для плагинов

В AST хранить просто как отдельные операторы/декларации. Это позволит покрыть 99.99% синтаксис и избавиться от проблем типа #55

Анализ областей действия инструкций препроцессора при необходимости можно будет выполнить в визитере

Разбирать только простейший случай, когда строка начинается с SELECT

В процедуре VisitPrepExpr добавлен цикл:

For Each Hook In Visitor.Hooks.AfterVisitVisitPrepExpr Do
	Hook.AfterVisitVisitPrepExpr(PrepExpr, Visitor.Stack, Visitor.Counters);
EndDo;

Похоже ошибка, наверное имелось ввиду AfterVisitPrepExpr.

Не переваривает такой код:
SubsystemIndex = ?(SubsystemDescription.Parent = Undefined, RolesTree.Rows, SubsystemDescription.Parent.Rows).IndexOf(SubsystemDescription);

Попробовать переделать с использованием StrFind():

• ScanStringLen
• ScanComment

Бакенд должен быть просто разновидностью плагина

Сейчас вылетает ошибка "Expected operand" из-за унарного минуса

Function Foo(Par1 = -1)

Передавать родителя (элемент связанного списка) параметром в хук, чтобы в плагинах была возможность подняться вверх по дереву при необходимости.
В сами узлы добавлять родителя нельзя, т.к. появятся циклические ссылки

Например, есть счетчик Visitor.Info.WhileStmtCount. При обходе подчиненных узлов цикла While увеличиваем счетчик на 1. При завершении обхода соответственно уменьшаем счетчик на 1.
Предполагается, что такая информация будет полезна в плагинах. Например, если плагин подписан на узел NewExpr и распознает создание запроса, то простая проверка Info.WhileStmtCount > 0 позволит выявить создание запроса внутри цикла (пример отстойный, да).

• Избавиться от реквизитов обработки парсера
• Убрать лишние запятые в конструкторах структур (а может и вообще эту кухню переиграть)
• Разбор инструкции препроцессора #Использовать
• Проверить все плагины

https://github.com/Lead-Bullets/BSL-Parser/blob/323cd8760face078e2dcdfacd2a595887c5e3126/src/BSL-Parser/Ext/ObjectModule.bsl#L2385

Структура такая
Return Struct("TryStmt",
"Try" // array (one of #Statements)
"Except" // array (one of #Statements)
"Place" // undefined, structure (Place)
, TryPart, ExceptPart, Place);

Сейчас ERP разбирается за 17 минут на ноуте 2.4ГГц (8 параллельных фоновых заданий)
Показатель неплохой, но кажется можно ускориться еще примерно в 2 раза.
Примерно 80% времени парсер тратит на разбор выражений, которые сейчас разбираются классическим рекурсивным спуском. Рекурсивный спуск требует большого количества вызовов функций, а это не дешево. Дешевле было бы выполнять разбор выражения по возможности в рамках одной функции.
Придумал вчера алгоритм разбора бинарных выражений со сложностью примерно O(n^2) который выполняется быстрее рекурсивного спуска по крайней мере на типовом размере выражений (0-3 оператора). Но выигрыш в целом небольшой, т.к. львиная доля затрат разбора в текущей реализации падает на анализ указателей(DesigExpr) и селекторов(SelectExpr).
Нужно попробовать унифицировать структуру выражений так, чтобы большая часть выражений была бинарной и пригодной для общего алгоритма. Грубо говоря все сводится к избавлению от сущностей DesigExpr и SelectExpr

Еще можно попробовать алгоритм сортировочной станции. Возможно он даже эффективнее, т.к. O(n).