Добрый день, товарищи.
Есть где-нибудь уже готовый скомпонованный grammar для C++20? Любой вменяемый формат подойдет. Об этой версии знаю, но она несколько размазанная и formatting-dependant, к тому же. Можно, конечно, распарсить, но это потенциально велосипед изобретать, так что решил все-таки заранее спросить. Вне стандарта тоже искал, но, к сожалению, ничего сколь-нибудь актуального и полноценного не нашел.

ну как минимум у этого сайта есть исходники (отмассажированный форк исходников стандарта) https://github.com/Eelis/draft/tree/cxxdraft-htmlgen-fixes/source

Там ни в одном бранче сколь-нибудь полноценного исходника Annex A нет. Только A.2 представлен. Хотя, возможно, это я в глаза долблюсь, конечно.

оО, а откуда такие штуки? А там есть разбор анализатора из Rider'а для C#?

ну я просто тоже пишу Идею :)
райдер в другой репе лежит

Коллеги, парсер -комбинаторы это фишка в основном фп? Реализовывать его на  не функциональных яп это костыль и какие есть аналоги?

А к райдеру доступа нетю?🙃 Может есть описание какое-нибудь со схемками/диаграммками

доступ у меня есть, схем никаких нет

Самое близкое — recursive descent, говорят (смотря что именно имеется в виду под тем и другим, я так понимаю).

Рекурсивный спуск на сколько я понимаю не позволяет делать восстановление после ошибок. Для восстановления уже нужно переходить на LL с предикатным анализом

Про райдер может @fvnever рассказать, если есть что рассказывать

Я вот не знаю, он в анализаторы и парсеры копал или нет:)

Это смотря как его понимать (я не знаю точного определения, извините).
Если писать в этих процедурах не только трансляцию продукций, а что-то ещё — можно делать и парсить вообще всё что угодно (т.е. в таком понимании это просто подход к структурированию кода ad-hoc parser-а).

Хз как именно правильно делать восстановление ошибок, но я в LL делал (кастомно задается, если есть возможность один токен recover'нуть) + Ещё у меня такая фигня, что окончание statement'а может быть и перенос строки и ; из-за этого приходится делать виртуальные ;, это наверное тоже под recovery подпадает.
Rust до (относительно) недавнего времени был полностью LL, и не смотря на то, что всё же добавился LR only синтаксис, там очень много возможностей по восстановлению ошибок.
И к тому же это реализовано не только локально для каждого правила, а и для всяких общих конструкций (там задаются возможные варианты recovery для блоков и тд, и парсер пытается восстановить).

Не особо вижу проблем с recovery в LL граматике.
Ну, к примеру есть 'fn' IDENTIFIER '(' ')' block, и если мы скормим парсеру какую-нибудь фигню вроде fn ;foo;(;); {;}; это будет очень легко восстановить, тут лишь вопрос в том, насколько безопасно восстанавливать дальше одного токена + так как грамматика LL, то First никак, очевидно, не вылечить (под First в данном случае подразумеваю 'fn' keyword)

UPD: Хотя... First лечится также по-сути. Если мы прошли все варианты, то у нас на руках ошибка "Unexpected token", а дальше мы снова начинаем, так что First конструкций, в принципе, лечится

First в рамках рекурсивного спуска у нас есть, а вот Follow нет

Кстати не знаю для чего на самом деле используется восстановление после ошибок, но в моём понимании это позволяет искать все ошибки, а не только первую

Почему же нет? Обычно с помощью LL парсят как раз-таки варианты, когда мы по First точно можем угадать Follow, или же сделать ветвление и ошибку, если не один из текущих токенов не подходит под Follow, и это всё ещё даже LL(0) 😌

ага. для компиляторов очень важно. хотя вот я не понимаю почему бы какой-нибудь js не парсить сразу с восстановлением. В любом случае сперва ВСЁ парситься для разрешения имен forward declared функций

Так что делать если у меня C# :)

Что посоветуете?