L
Size: a a a
2020 November 27
s
It's easier to write a email parser than a email regex.
2020 November 28
IJ
Великолепный сборник примеров программ на С, которые могут сломать наивный парсер языка, и вообще демонстрируют странное поведение.
https://blog.robertelder.org/building-broken-c-parsers/
https://blog.robertelder.org/building-broken-c-parsers/
PS
Великолепный сборник примеров программ на С, которые могут сломать наивный парсер языка, и вообще демонстрируют странное поведение.
https://blog.robertelder.org/building-broken-c-parsers/
https://blog.robertelder.org/building-broken-c-parsers/
Адрес которого из массивов будет возвращен? :)
int arr[100];
int arr[100];
int *main(void) { return arr; }H
Адрес которого из массивов будет возвращен? :)
int arr[100];
int arr[100];
int *main(void) { return arr; }tentative definitions?
PS
tentative definitions?
Ага. А вообще, в процессе реализации собственного компилятора Си очень много подобных примеров отыскивается.
Но сборник по ссылке @igorjirkov все равно хороший :)
Но сборник по ссылке @igorjirkov все равно хороший :)
IK
Можно попробовать их поискать с помощью чего-нибудь вроде https://github.com/nautilus-fuzz/nautilus
M
Сушествует прям жесткая градация между expr и stmt? Тоесть к примеру - возврашает значение expr, не возврашает stmt
M
Потому что все эти "производит действие" это какая то размытая категория
H
Сушествует прям жесткая градация между expr и stmt? Тоесть к примеру - возврашает значение expr, не возврашает stmt
в си можно из expr сделать stmt просто добавив
;H
у expr тип
T, у stmt unit type по логикеD
Но кажется у Си есть stmt, которые возвращают значения
Или это расширение?
Или это расширение?
H
вроде нет в стандарте
H
gcc statement expressions?
H
жутко удобная штука кстати, очень жаль, что в стандарте нет
D
gcc statement expressions?
Ага, я про них
💎
Всем привет! Где можно почитать о проектировании деревьев разбора и восстановлении ошибок для LL анализатора ?
Как пример взять тот же Rust, такие красивые ошибки по типу найденного бесконечного цикла, или macro paniced/macro invocation, показывает где начинается проблема и где она заканчивается, строятся же из синтаксического дерева? К примеру узлы Expr при нахождении ошибки заменяются на BadExpr который показывает прямо в дереве где ошибка началась и где она закончилась. Приведу пример:
Как пример взять тот же Rust, такие красивые ошибки по типу найденного бесконечного цикла, или macro paniced/macro invocation, показывает где начинается проблема и где она заканчивается, строятся же из синтаксического дерева? К примеру узлы Expr при нахождении ошибки заменяются на BadExpr который показывает прямо в дереве где ошибка началась и где она закончилась. Приведу пример:
TypeDecl { Child Expr, Parent Expr }
type int_alias = 77Int; // так как ошибка была найдена в узле Parent, мы устанавливаем Parent как BadExpr {from_position, to_position } и это в свою очередь являет '77int'
Далее мы рекурсивно анализируем дерево и при обнаружении в корневом узле к примеру ForDecl, узел BadExpr , выдаем красивую ошибку от начала ForDecl from_position до ForDecl.BadExpr to_position
Этот подход верный?2020 November 29
AT
Всем привет! Где можно почитать о проектировании деревьев разбора и восстановлении ошибок для LL анализатора ?
Как пример взять тот же Rust, такие красивые ошибки по типу найденного бесконечного цикла, или macro paniced/macro invocation, показывает где начинается проблема и где она заканчивается, строятся же из синтаксического дерева? К примеру узлы Expr при нахождении ошибки заменяются на BadExpr который показывает прямо в дереве где ошибка началась и где она закончилась. Приведу пример:
Как пример взять тот же Rust, такие красивые ошибки по типу найденного бесконечного цикла, или macro paniced/macro invocation, показывает где начинается проблема и где она заканчивается, строятся же из синтаксического дерева? К примеру узлы Expr при нахождении ошибки заменяются на BadExpr который показывает прямо в дереве где ошибка началась и где она закончилась. Приведу пример:
TypeDecl { Child Expr, Parent Expr }
type int_alias = 77Int; // так как ошибка была найдена в узле Parent, мы устанавливаем Parent как BadExpr {from_position, to_position } и это в свою очередь являет '77int'
Далее мы рекурсивно анализируем дерево и при обнаружении в корневом узле к примеру ForDecl, узел BadExpr , выдаем красивую ошибку от начала ForDecl from_position до ForDecl.BadExpr to_position
Этот подход верный?В rustc обнаружение, восстановление и отображение ошибок наверняка тщательно написано руками, без генераторов.
Для LR на Rust есть отличная работа Лоуренса Тратта: https://tratt.net/laurie/blog/entries/automatic_syntax_error_recovery.html Но можно этот подход перенести и на другие системы. Что-то лучше из автоматического вряд-ли есть.
Для LR на Rust есть отличная работа Лоуренса Тратта: https://tratt.net/laurie/blog/entries/automatic_syntax_error_recovery.html Но можно этот подход перенести и на другие системы. Что-то лучше из автоматического вряд-ли есть.
M
Я вот писал транслятор си АСТ в llvm ir, придерживаясь конвенции что у меня на вход дано изначально верное АСТ. Сейчас вот думаю, как бы описать правила что есть верное АСТ, что бы инкркментно проверять стало ли АСТ верным. Какие есть идеи?
DP
сейчас тебе какие-нибудь мутные типы насоветуют 8)