ediah / flower Goto Github PK

На тестах случайным образом (когда-то есть ошибка, а когда-то -- нет) вылезает "Segmentation fault". С чем это связано, пока не знаю.

Вот пример, на котором оптимизация не срабатывает:
https://github.com/ediah/mlc/blob/65cdee2ab97b552d6fdf2fc6244af34704de2c44/test/A-unit/unit21.ml#L7
Можно было бы подумать, что виновато отсутствие скобок в последнем произведении, но нет, оптимизатор не смог вынести даже две повторяющиеся скобки, хотя в предыдущих строках этого теста скобки оптимизируются.

Во время просчёта теста test/A-unit/bench1.ml возникают проблемы с памятью. Скорее всего, повреждается стек.
Нужно больше памяти? Оптимизировать stack.cpp? Или это мой косяк?

Иметь много подготовленных тестов для выявления возможных ошибок -- это здорово. Но когда покрытие кода растёт, запуск и проверка результатов вручную становятся затруднительными. Есть два предложения:

1. Либо это должен быть отдельный инструмент (например, test/test.cpp), папка с входными и выходными данными. И тогда его обязанности мне представляются следующими:

• Компиляция исходного кода. При этом он должен проверить, чтобы все тесты группы A скомпилировались, а все тесты группы B выдали те ошибки, которые ожидалось получить.
• После этого шага идёт запуск скомпилированных программ на входных данных с последующей сверкой вывода.
• Опционально сюда можно добавить прохождение обоих этапов с применением Valgrind, а в связи с идеей реализации оптимизатора -- проверку эквивалентности и скорости выполнения.

2. Либо сделать автотест частью языка и компилятора.

• Ключевые слова input и output будут задавать входные и выходные данные соответственно. Если компилятор встречает эти области в исходном коде, то он "вшивает" их в исполняемый файл.
• При запуске виртуальная машина собирает тестовые данные и использует их в операциях read() и write(), в результате чего даёт отчёт: все ли тесты были пройдены, какие провалились.

Лично мне оба варианта нравятся, и в качестве тренировки мог бы реализовать и то, и то.