Очень полезная вещь, думаю на немерле реализовать нечто подобное не составит труда, так как парсеры уже есть.
Думаю этим заняться в ближайшее время.
Собсвенно думаю как лучше это делать
Макрос уровня сбоки, который проводит анализ и выдает ворнинги.
Встроить в компилятор, и макротраибутом наоборот отключать анализатор
отдельная StandAlone утилита
Здравствуйте, BogdanMart, Вы писали:
BM>Собсвенно думаю как лучше это делать
По-хорошему такой анализ нужно выполнять на уровне типизированного дерева.
Т.е. следует добавить в API компилятора возможность выполнять анализ/преобразование TExpr перед T2.
Здравствуйте, hardcase, Вы писали:
H>По-хорошему такой анализ нужно выполнять на уровне типизированного дерева. H>Т.е. следует добавить в API компилятора возможность выполнять анализ/преобразование TExpr перед T2.
Думал вообще чисто роспаршеное, до применения макросов анализировать. Так как розвернутые макросы анализировать ... это какой то капец может выйти думал считать, что макросы без логических шибок.
По идеи можно правила анализа применять на разных стадиях. Простые на стадии до типизации например.
Сначала наверно делать анализатор макросом, а потом уже куда то перенести?
Здравствуйте, BogdanMart, Вы писали:
BM>Собсвенно думаю как лучше это делать
BM>
BM>Макрос уровня сбоки, который проводит анализ и выдает ворнинги. BM>Встроить в компилятор, и макротраибутом наоборот отключать анализатор BM>отдельная StandAlone утилита BM>
Такие вещи нужно делать на стадии компиляции T2-T4. Можно сделать некий набор событий и подключаться к ним. Делать это макросами неудобно, так как для анализа нужно иметь полностью типизированное АСТ. Плюс анализ имеет смысл писать для корректного АСТ, а это бывает не всегда (про ошибки забывать не стоит).
Немерл, в отличии от С++, делает множество проверок, так что огромной надобности в таком анализе нет. Но в приципе это дело, кончено, не помешает.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, hardcase, Вы писали:
H>По-хорошему такой анализ нужно выполнять на уровне типизированного дерева.
+1
H>Т.е. следует добавить в API компилятора возможность выполнять анализ/преобразование TExpr перед T2.
А вот это вопрос спорный. Думаю, что нужно позволять делать такой анализ перед и после любого Tх-шага. А когда его запускать разработчик должен решать сам.
Ну, и, естественно, такой код должен быть плагином. Не фига раздувать компилятор.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
BM>Думал вообще чисто роспаршеное, до применения макросов анализировать. Так как розвернутые макросы анализировать ... это какой то капец может выйти
Все с точностью до наоборот. Анализировать нужно именно развернутый код. Это в сто раз проще. Там все ссылки разрешены.
На самом деле статический анализ кода — это целая область науки. Там все совсем не просто. Возможно перед таким анализом имеет смысл переписать код в специальное представление (для анализа потока управления).
BM>По идеи можно правила анализа применять на разных стадиях. Простые на стадии до типизации например.
До типизации недостаточно информации. Ты будешь вынужден повторить типизацию. А это, в условиях вывода типов, очень не простая задача.
Единственное что можно сделать — это производить анализ PExpr после того как типизация будет закончена и использовать значение свойства TypedObject. Тогда можно будет совместить преимущества анализа исходного языка (не преобразованного макросами) и наличие информации о типах.
BM>Сначала наверно делать анализатор макросом, а потом уже куда то перенести?
Макросом такие вещи делать невозможно. Без информации о типе полноценный анализ не сделать.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, BogdanMart, Вы писали:
VD>>Ну, и, естественно, такой код должен быть плагином. Не фига раздувать компилятор.
BM>А как эти самые плагины к нему подключать?
Элементарно, в общем-то. В ManagerClass добавить события срабатывающие после T-стадий: Typer.n Typer2.n Typer3.n Typer4.n
В событиях на входе передавать TExpr тел методов (для стадии идущей после T1 можно так же передавать исходное PExpr в рассчета на то, что информация о типах может браться из его свойства TypedObject), а на выходе это событие будет возвращать модифицированный TExpr или null (если ничего не изменено). Для следующей стадии будет использоваться этот возвращенный TExpr или исходный, если возвращен null. Если во время обработки события будет сгенерированно сообщение об ошибке, то дальнейшая обработка останавливается (чтобы предотвратить генерацию кода по неверному АСТ).
Для целей анализа нужно будет всегда возвращать null (так как изменения кода не производится) и выдавать сообщения об ошибках или предупреждения, если найдены проблемы.
Отдельный вопрос как грузить сборки которые будут подключаться к этим событием. Самое простое что приходит в голову — это реализовать подключение в макро-атрибутах уровня сборки.
Можно так же сделать и отдельную загрузку плагинов, но это уже надо Хардкейса дергать. Он у нас по части плагинов.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>В событиях на входе передавать TExpr тел методов (для стадии идущей после T1 можно так же передавать исходное PExpr в рассчета на то, что информация о типах может браться из его свойства TypedObject), а на выходе это событие будет возвращать модифицированный TExpr или null (если ничего не изменено). Для следующей стадии будет использоваться этот возвращенный TExpr или исходный, если возвращен null. Если во время обработки события будет сгенерированно сообщение об ошибке, то дальнейшая обработка останавливается (чтобы предотвратить генерацию кода по неверному АСТ).
Да, совсем забыл упомянуть одну тонкость. События дотнета, точнее делегаты, по сути, являются массивами ссылок на функциональные объекты. По сему к одному событию может подключиться более одного обработчика. Так как обработчики могут возвращать значения, то нельзя использовать вызов делегата напрямую. Вместо этого нужно распаковывать список вызовов и вызвать их вручную, передавая возвращаемое значение одного обработчика на вход другого (если, конечно, первый не вернул null).
Так же, возможно, имеет смысл предусмотреть некий механизм задания приоритетов выполнения таких делегатов. В прочем, возможно — это лишнее.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
думал считать, что макросы без логических шибок.
