Парсинг c++ кода

такое скармливается в LanguageServer (их много разных) и его выхлоп уже окончательно разбирается.

можно скормить в любой highlight`ер который отдаёт xml/html. Их тоже много.

ну и конечно «некоторое полное выражение ЦПП» отдельно от прочего контекста корректно не разбирается. Шаблоны и макросы этому препятствуют

castxml?

Насколько я знаю, следует смотреть в сторону clang.

Вот для python: https://stackoverflow.com/questions/36808565/using-libclang-to-parse-in-c-in-python

Использовать llvm (libtooling или как его там). Но нужно будет указать пути ко всем includ’ам и так далее. Их можно получить, к примеру, из compilation database.

Можешь почитать одну из предыдущих тем. Там 5 страниц комментариев и много вкусных ссылок.

CastXML содержимое функций игнорирует.

Надо заворачивать в

void func() {
    // your statement here
}

и отдавать SrcML либо попробовать соответствующий tree-sitter парсер. Выхлоп последнего для плюсов не видел. SrcML бывает тупит, но в большинстве случаев парсит нормально (хотя там с параметрами шаблона при вызове функций был бок). Вроде видел ещё какой-то парсер на питоне, но не помню насколько он полный был (там что-то типа линта было).

Спасибо за ссылки, почитаю. Немного подумав над задачей, пока в голове крутится мысль - не такая уж она и сложная, нужно лишь найти все бинарные операторы в текущем выражнии/подвырожении (вложенные парсить не надо), следовательно, не страшен ни трехэтажный шаблон, ни хитрая последовательность скобок, все что осталось - операнды. Если совсем заморочиться, то можно и через препроцессор прогрнать исходник. Синтаксический анализ не нужен. Вроде звучит просто.

Clang за тебя сделает всё указанное. И через препроцессор прогонит, и шаблоны развернет.

typename boost::enable_if<x, Type>::type

typename пространство_имен::шаблон<x, Type>::type

typename boost::enable_if< x, Type > ::type

typename пространство_имен::статическая_константа меньше x оператор_запятая Type больше ::type

Это почему невозможно парсить c++ без контекста

Ну ты и обленился =). Неужели оно настолько огромное что нельзя отформатировать? Минифицированный с++? Эт кто так над тобой пошутил?

В общем соглашусь, застрял именно на шаблонах. Ну вот как отличить оператор больше меньше от параметризации шаблона? Т.е надо делать синтаксический анализ, а это уже задача другого уровня. Брать шланг - ну видимо остается лишь это, хотя я не сильно в восторге от такой зависимости, т.к. поделка уже зависит от ГЦЦ и шлангом не заменить.

Кстати, может слухи ходят - есть ли у ГЦЦ в планах давать наружу своё AST? Ну т.е. подобно шлангу для взаимодействия со всякими инструментами?

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

Еще foo((1, 2))

Кстати, может слухи ходят - есть ли у ГЦЦ в планах давать наружу своё AST? Ну т.е. подобно шлангу для взаимодействия со всякими инструментами?

Не давать AST было принципиальной позицией. Хотя помню, что кто-то реализующий модули (которые по сути дамп AST) показывал исправленное синтаксическое дерево (до этого оно было неполным) и говорил, что осталось только отдать его наружу, но не уверен, что это что-то изменило.

Не давать AST было принципиальной позицией.

Странная какая-то ерунда, я что-то не очень понимаю - в чем страх вообще, что я возьму от ГЦЦ АСТ и начну из него бинари клепать? Зачем мне это надо и почему шланговское АСТ мне не подойдет? Да и упомянутые модули.

Ну жаль, что они сами себя закапывают.

Пока кланга не было они выражали опасения, что это позволит пилить проприетарные IDE на основе GCC. Так как оно давно и без GCC есть, то может передумают когда-нибудь. Там что-то ещё в 2015 обсуждали.

А gcc-xml это не то?

https://gccxml.github.io/HTML/Download.html

Вот только не знаю, дружит ли оно с современным gcc.

Это был неофициальный форк.

так там же в новостях:

Current news is listed in the following.
    2015-03-26: GCC-XML has been succeeded by CastXML. 
...

а CastXML и сам сидит на libclang. Ну я думаю, зачем мне ещё одна абстракция над libclang? Пытаюсь разобраться как работать с AST через libclang напрямую, штудирую инфу.

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

i = ...;

И вот споткнулся на таких конструкциях:

q = S<a,b>(c-d);
q = S<a,b>::c;

С большой вероятностью можно предположить, что это не (q = S<a),(b>(c-d)). Но по-любому какую-нибудь конструкцию я не учту.

Я забросил идею парсить АСТ сбоку, хочу запилить плагин для компилятора и парсить его АСТ во время нормальной компиляции и выдавать предупреждения (в этом и цель всего этого меропирятия, нужных ворингов нет). Получается, что можно всунуть плагин как в шланг, так и в ГЦЦ. Предпочтительнее все же ГЦЦ, но есть ряд сомнений - достаточно ли документировано АСТ у ГЦЦ, можно ли его комфортно распарсить, или это боль и лучше взять Шланг? Пока я глубоко не погрузился в чтение доков и попытки понять ГЦЦ - может есть какой опыт и можете что-нибудь посоветовать по поводу выбора компилятора?

http://icps.u-strasbg.fr/~pop/gcc-ast.html

https://gcc.gnu.org/onlinedocs/gccint/GENERIC.html

И пример использования https://jongy.github.io/2020/04/25/gcc-assert-introspect.html

Продублирую ссылку на документацию GENERIC, но в виде дерева. У monk другие ссылки отличные.

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

И там и там интерфейс плагинов – просто внутренности компилятора. Т.е. стабильность не гарантируется, но у GCC изменений меньше, да и старое вроде как не спешат удалять, в кланге много wannabe-web-макак, которые так и норовят «обновить» исходники и сломать этим совместимость.

Я бы попробовал на GCC, чтобы не мешать компиляторы.

Clang за тебя сделает всё указанное. И через препроцессор прогонит, и шаблоны развернет.

«Ты что! Шланг же не ГПЛ!!111одинодин»

ок, спасибо.