Привет,

Подскажите плз, что нужно сделать чтобы в выхлопе pretty print-a присутствовали комментарии?\
У нас сейчас они как в примерах описаны

    extend token IgnoreToken
    {
        | [SpanClass(Comment), ExplicitSpaces] SingleLineComment;
        | [SpanClass(Comment), ExplicitSpaces] MultiLineComment;
    }

Здравствуйте, pekabon, Вы писали:

P>Подскажите плз, что нужно сделать чтобы в выхлопе pretty print-a присутствовали комментарии?\

К сожалению, сейчас это не поддерживается.

Здравствуйте, pekabon, Вы писали:

P>Подскажите плз, что нужно сделать чтобы в выхлопе pretty print-a присутствовали комментарии?

Пока никак. Постараемся придумать что-то в ближайшее время.

С какой целью нужны комментарии?

Здравствуйте, VladD2, Вы писали:

VD>С какой целью нужны комментарии?

Мы заготовку для скрипта, который будет редактировать пользователь, генерируем и добавляем туда комментарии.
На этом этапе для форматирования текста пользуемся парсером — парсим и делаем pretty print.
В принципе можем и сами обойтись — сгенерировать уже красивый скрипт.

Здравствуйте, pekabon, Вы писали:

P>Мы заготовку для скрипта, который будет редактировать пользователь, генерируем и добавляем туда комментарии.
P>На этом этапе для форматирования текста пользуемся парсером — парсим и делаем pretty print.

То есть Коментарии вы хотите не из исходника брать, а собственные добавлять?

Здравствуйте, VladD2, Вы писали:

VD>То есть Коментарии вы хотите не из исходника брать, а собственные добавлять?

Из исходинка. Просто мы "рыбу" генерим в текстовом виде.

Здравствуйте, VladD2, Вы писали:

VD>Пока никак. Постараемся придумать что-то в ближайшее время.
VD>С какой целью нужны комментарии?

Нам опять понадобились комментарии в pretty print — для автоформатирования исходников в студии.
Ничего не придумалось?

Здравствуйте, pekabon, Вы писали:

P>Нам опять понадобились комментарии в pretty print — для автоформатирования исходников в студии.
P>Ничего не придумалось?

По началу не верно прочел...

Тут есть следующие соображения. Можно добавить в дерево разбора ветки для S-ок (пробельных правил), но это сильно раздует дерево разбора.

Возможно лучше будет пойти одним из следующих путей:
1. Добывать информацию об s-ках (пробельных правуилах) через Walker.
2. Получать всю необходимую для форматирования информацию через Walker.

В первом случае вы так и будете использовать ParseTree, но информацию о пробельных правилах (содержащих коменты) будете получать отдельным вызовом.

Во втором можно обойтись вообще без ParseTree. Это сделает алгоритм быстрее (и возможно даже проще).

В любом случае вам нужно создать наследника класса WalkerBase и переопределить в нем нужные методы.

Посмотрите VoidRuleWalker — он делает нечто похожее на то что нужно вам. Он собирает информацию о пробельных правилах. Вам нужно будет сделать его аналог и несколько его усугубить вынимая и кишки пробельных правил.

Для понимания того как работают Walker-ы советую сделать фильтрацию по "Walker" в Solution Explorer нитровского проекта. Например, HighlightingWalker собирает информацию о ключевых словах и прочих токенах.

Возможно для форматирования вам лучше будет собрать список токенов (включая пробельные) для каждой конструкции и реализовать форматирвоание на нем.

Здравствуйте, VladD2, Вы писали:


VD>По началу не верно прочел...

VD>Тут есть следующие соображения. Можно добавить в дерево разбора ветки для S-ок (пробельных правил), но это сильно раздует дерево разбора.

Понятно
А как вообще планируется применять встроенный Pretty printing, который печатает с учетом всяких nl, но выкидывает комментарии?

Здравствуйте, pekabon, Вы писали:

P>Понятно
P>А как вообще планируется применять встроенный Pretty printing, который печатает с учетом всяких nl, но выкидывает комментарии?

Использовать прети-принт для форматирования мы не планировали никогда. Прети-принт он для других целей совсем.

Вопрос форматирования (если к нему подходить серьезно) он довольно не прост. Сейчас попробую описать все по подробнее.

Дело в том, что форматирование должно быть настраиваемым. Например, кто-то предпочитает ставить скобки так:

if (x)
{
}

а кто-то так:

if (x) {
}

Таких мест куча.

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

По сему описывать форматирование маркерами не получится.

Была идея сделать внешнее описание форматирования в виде паттерн-матчинга.
Описываем паттерн:

if ($Expr) nl
{ inl
  $Statments nl d
}

У нас даже был прототип генератора поттерн-матчинга, но мы его выкинули, так как он не использовался, а его компиляция для рагамматики замедляла процесс компиляции в 2.5 раза.

Как временное решение можно докрутить прети-принт, чтобы он использовал содержимое пробельных (void) правил.

Можно даже сделать прети-принт Raw AST (бинарному AST-у). Для этого нужно сделать Walker в котором генерировать текст. Такое решение будет работать очень быстро и ему будет доступны все данные о дереве разбора (в том числе и внутренности пробельных правил).

Здравствуйте, VladD2, Вы писали:

VD>Тут есть следующие соображения. Можно добавить в дерево разбора ветки для S-ок (пробельных правил)

Нужно. Без этого про рефакторинг можно забыть.

Здравствуйте, AndrewVK, Вы писали:

VD>>Тут есть следующие соображения. Можно добавить в дерево разбора ветки для S-ок (пробельных правил)

AVK>Нужно. Без этого про рефакторинг можно забыть.

Отнюдь. Информация об s-ках есть в Raw-Parse Tree. Причем в очень детальном виде. В тории можно вообще без материализованного дерева разбора жить. И это несколько ускорит обработку. Просто это очень не просто реализовать.

В прочем, дерево разбора сейчас ленивое, так что жертвуем только дополнительными полями.