Баги парсера, выявленные тестами

[impworks]

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

1. На парсятся дробные числа. Тест NewObjectDeclaration проходится, если 13.37 заменить на 13.

[ForNeVeR]

Внезапно, в грамматике тоже только int. Я пофикшу в парсере, а ты посмотри грамматику - всё ли там ок?

[ForNeVeR]

Исправлено. Тикет не закрываю - вдруг ещё что-то найдём.

[impworks]

Не парсится такая, вполне вроде бы легальная строка:

1.GetHashCode ()

А вот такая - вполне:

(1).GetHashCode ()

Посмотри пожалуйста, почему так происходит. Может быть, бага в грамматике?
P. S. Строчка ниже не только парсится, но уже работает :)

[ForNeVeR]

lvalue = [ type "::" ] identifier { accessor_expr } | "(" expr ")" accessor_expr { accessor_expr }

Как видишь, для применения accessor_expr нужно брать expr в скобки. Я бы не стал сейчас это менять - кажется, без этого у нас могут возникнуть какие-нибудь проблемы.

Точно. Убрал в парсере скобки и получил StackOverflowException на этапе парсинга.

@impworks, считаю такое изменение лишним, раз уж оно валит парсер. Для lens 2.0 мы, может, запилим самодельный парсер или что-нибудь в этом роде, а пока что не вижу смысла вносить такие ломающие изменения.

[impworks]

Попробуй такие изменения в грамматике:

lvalue              = [ type "::" ] identifier { accessor_expr } | atomar_expr accessor_expr { accessor_expr }
value_expr          = atomar_expr | lvalue
atomar_expr         = literal | type_operator_expr | "(" expr ")"

[ForNeVeR]

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

[impworks]

Сначала lvalue? А почему так стало лучше?

[ForNeVeR]

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

[impworks]

Нашел еще один баг. В тестах BareLambda и ParametricLambda создается FunctionNode - видимо, я забыл это поменять, когда проводил рефакторинг. Должна создаваться LambdaNode.

[impworks]

Не парсится следующий, на мой взгляд, корректный код:

fun test -> 10
test ()

Почему?

[ForNeVeR]

В тестах BareLambda и ParametricLambda создается FunctionNode

Исправлено: 855be00. Оказалось, что лямбды есть ещё в паре тестов - там тоже поправил.

[ForNeVeR]

Не парсится следующий, на мой взгляд, корректный код

Была проблема в грамматике - после funcdef не ожидался перевод строки. Было:

funcdef             = "fun" identifier func_params "->" block

Стало:

funcdef             = "fun" identifier func_params "->" block NL

Добавил тест, починил грамматику и парсер. 9c415f3.

[impworks]

Не было бы правильнее требовать от самого block, чтобы он заканчивался
переносом строки или EOF? Чтобы еще где-нибудь не забыть.

[ForNeVeR]

Дело в том, что там не только block, но и local_expr, от которого
требовать новой строки нелогично. Сначала я так и попробовал, но отвалился
код с однострочным if-then-else.

[impworks]

Почему-то не парсятся операторы <= и >=.
См. тест OverloadedOperators.

[ForNeVeR]

Была проблема в грамматике и парсере, пофикшено: 96528e0.