Многие нас заслужено ругают за то, что мы не отчитываемся о ходе работ над Nitra.
Решил, вот, вместо отчета показать одну картинку. Это диаграмма содержащая DAG-а (направленного ациклического графа) описывающий "лес" стеков получающихся при восстановлении следующего C#-кода:
A {}
Вот тот же код с индексами символов, чтобы проще было понять, что означают цифры в диаграмме:
Диаграмма
Вот такими методами мы отлаживаемся и ищем алгоритмы восстановления. Что называется — оцените масштаб задачи.
Картинка векторная, так что ее можно легко масштабировать.
Линии со стрелочками описывают связи между фреймами стека. Зелеными стрелками описываются пути через которые удается произвести восстановление (не тупиковые пути).
Наша задача на сегодня выбрать из этого списка "головы" являющиеся наиболее разумными, с точки зрения человека, продолжения. Пофиксить данные парсера в соответствии с выбором и продолжить парсинг. При фиксе данные парсера меняются так, чтобы он пропускал те или иные подправили и грязь (части текста которые нельзя разобрать даже путем пропуска подправил).
Лучшими фреймами являются: Id=67 (Class), Id=58 (StructHead), Id=38 (Enum), Id=48 (InterfaceHead). А вот описание этих правил:
syntax StructHead = "struct" Name;
syntax InterfaceHead = "interface";
syntax TypeDeclaration
{
| Class = Attributes Modifiers Partial? "class" Name TypeParameters? TypeBase? TypeParameterConstraintsClauses d TypeBody;
| Struct = Attributes Modifiers Partial? StructHead TypeParameters? TypeBase? TypeParameterConstraintsClauses d TypeBody;
| Interface = Attributes Modifiers Partial? InterfaceHead Name TypeParameters? TypeBase? TypeParameterConstraintsClauses d TypeBody;
| Enum = Attributes Modifiers "enum" Name EnumBase? EnumBody;
| Delegate = Attributes Modifiers "delegate" AnyType Name TypeParameters? "(" FormalParameters ")" TypeParameterConstraintsClauses? ";";
}
StructHead и InterfaceHead введены чтобы жизнь медом не казалась.
Если кому-то интересно. Информация внутри квадратиков расшифровывается следующим образом.
Сначала идет имя правила для которого создан фрейм. SP — позиция с которого начала парситься ветка AST к которой относится данный фрейм, TP — позиция с которой начал парситься данный фрейм (для одной ветки AST может быть более одного вложенного фрейма), FS — номер подправила на котором упал парсинг (FailState), T — тип фрейма (возможные варианты: Root, Extensible, ExtensiblePrefix, ExtensiblePostfix, ListBody, ListSeparator, Rule), D — глубина фрейма (Depth), PA — список альтернативных пропарсиваний данного фрейма (ParseAlternatives). B — означает, что это потенциальный лучший фрейм (Best), S — спекулятивный фрейм (фрейм который был достроен по грамматике, а не получен от парсера).
ParseAlternatives имеют следующий формат. Сначала (за открывающей круглой скобкой) идет позиция начала парсинга. Далее идет позиция окончания парсинга. Если во время парсинга произошло падение, то позиция окончания парсинга предваряется буквой "F" (Fail). Далее, после двоеточия, идет длинна съеденных, дочерними элементами, символов. Далее идет состояние (т.е. порядковый номер подправила) с которого удалось произвести пропарсивание. Таким образом первые два числа показывают откуда и сколько было пропарсено, следующее число показывает сколько символов было пропасено в дочерних правила (идущих выше по стеку), а последнее сколько подправил пришлось пропустить для того чтобы продолжить парсинг.
Далее идет список пропарсиваний и разобранная ими строка. На каждой строке одна альтернатива пропарсивания. Данные дублируют то что отображается в PA, за исключением разобранной строки. Собственно ради нее это дело и дублируется.
Далее идет описание подправил правила для которого создан фрейм. Перед каждый подправилом указывается его порядковый номер (отделенный двоеточием). Этот номер мы называем состоянием (State).
ЗЫ
Не судите строго, это всего лишь отладочное представление информации. Просто хотелось поделиться с вами с чем приходится возиться.
