Облагородить сообщения об ошибках парсинга about lens HOT 15 CLOSED

Сделано две вещи:

1. Все синтаксические токены поименованы по-человечески (локализуемо, см. Grammar.fs - последний аргумент у функций вида createParser).
2. Сами тексты, которыми парсер оборачивает эти лексемы, тоже настраиваются. Пока сделал простенькую заглушечку: 46d0944

Можно делать любого рода облагораживание, но нужны более подробные требования к выводу ошибок. Предлагаю пока поработать с тем, что получилось, а в процессе полевых испытаний выработать другую стратегию обработки и вывода этих ошибок, если понадобится.

Вкратце - у нас на входе есть список всех ошибок, которые были возвращены нашими парсерами: что они ожидали получить, чего не ожидали (такого я пока ни разу не получал, но по идее бывает unexpected token), после каких ошибок произошёл откат. FParsec по умолчанию группирует эти ошибки (типа, expected a or b or c; unexpected d; nested error x; other <System.Object at 0xcafebabe]>), я такого делать пока не стал.

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

@impworks, когда прочитаешь этот комментарий - задачу можно закрывать (чтоб не висела), а потом уже по необходимости заведём новые, с более конкретными требованиями.

from lens.

Хорошо, пусть будет так. Закрываю.

from lens.

Текущая реализация выглядит как-то криво. Надо бы поправить как-нибудь.

from lens.

По-моему у нас сейчас все сообщения об ошибках слетели и показывается всегда одно и то же:

System.Exception : At line 2, column 1: Expected newline
Expected end of input
Expected statement

Нормальные сообщения - критически важная штука. Это первое, на что будет смотреть приемная комиссия.

from lens.

Нет, ничего не сломалось, так и должно быть. Просто когда парсер видит невалидный исходник - он начинает делать бактрак, пока не докатится до самого корневого узла. Вот и получается, что он не соответствует шаблону "statement". У нас там внутри должны быть сообщения более высоких уровней, так что можно (и нужно) дозаточить.

from lens.

Помоги только мне понять, какие сообщения должны быть.

from lens.

Начнем с этого:

• Везде, где не получается распарсить выражение - писать "Expression is expected" в наиболее близком к ошибке месте. Например, 1 + (2 * ???) - у первого вопросительного знака.
• Везде, где требуется тип - писать "Type is expected".
• Несовпадающие скобки всех типов - ( ) { } < > [ ]
• Cтрелка перед телом функции - "Function body is prefixed with ->"
• Двоеточие перед типом поля структуры - "FIeld name is followed by :"
• Точка с запятой между элементами инициализатора массива \ списка \ структуры \ кортежа - "Array\tuple... items are separated by ;"

from lens.

Столкнулся с тем, что типичный случай "Expected end of input; Expected statement" возникает, когда парсер вообще ничего в исходнике понять не смог. Он пытается пройтись по всем подряд подветкам выражения statement, не видит в них ничего хорошего, и выходит. Иногда он срабатывает нормально (во всяком случае, несовпадение скобок он встречает годным сообщением посреди мусора).

Навскидку пока рассмотрим такое решение:

• парсер собирает все ошибки, которые ему встретились в процессе парсинга, в специальной структуре;
• мы начинаем раскручивать эту кучу начиная с выражения, которое добралось дальше всех по структуре исходного файла;
• по токенам из грамматики можно будет выводить какие-то более-менее понятные сообщения.

from lens.

Мне кажется, нужно как-то его надоумить не всегда откатываться назад до самого первого символа. В некоторых случаях тупо выкидывать ошибку прямо на месте. Такие места в грамматике я могу перечислить, если необходимо.

from lens.

Это было бы весьма кстати.

from lens.

https://docs.google.com/document/d/1tzF2dFc_93rnLYWfaQB4xgkObhPoafkYkjw5HzDfI5o/pub

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

Синим выделены "хитрые" места, которые следует как-то особым образом учитывать. Например:

• "Else statement without condition"
• "Catch statement without try block"
• "Mismatched paren"
• В line_expr_3, если распарсилось "not" | "-", первый line_expr_4 также является неоткатываемым

Если что-то придет в голову, тоже запили.

from lens.

Да, кстати. Незакрытую кавычку строки и слишком здоровый числовой литерал также стоит отображать.

from lens.

Ну и, конечно же, "Inconsistent identation".

from lens.

В общем, пока что сделал всё возможное для нормального вывода ошибок. Получилось, вроде бы, нормально и локализовано. Со всякими "незакрытыми скобками" пока что заморачиваться не стал. Неужели непонятно, что, если "ожидается символ )" - это значит, что скобка не закрыта?

from lens.

Принимается. К версии 2.0 будет рукопашный парсер, в котором отображение ошибок будет улучшено.

from lens.