10. Что делать, если что-то идёт не так

10.1. Когда компилятор делает «неправильные» вещи

«Помогите! Компилятор упал (или завис)!»

Эти события всегда являются ошибками в системе GHC — пожалуйста, сообщите о них.

«Это ужасное сообщение об ошибке.»

Если вы считаете, что GHC мог бы вывести более понятное сообщение об ошибке, пожалуйста, сообщите об этом как об ошибке.

«А как насчёт этого предупреждения от компилятора C?»

Например: …warning: \`Foo' declared \`static' but never defined. Неприглядно, но не должно быть проблемой.

Sensitivity to .hi interface files

GHC очень чувствителен к файлам интерфейса. Например, если он обнаружит файл Prelude.hi нестандартного формата, произойдут довольно неприятные вещи.

Кроме того, как показано ниже, у вас могут возникнуть серьёзные проблемы при запуске программ, скомпилированных с использованием неустойчивых интерфейсов.

«Я думаю, GHC генерирует неправильный код»

Маловероятно :-) Полезным вариантом для GHC является -dcore-lint-dcore-lint; это выполняет «lint» проверку, чтобы обнаружить ошибки (в особенности ошибки типов) после каждого прохода преобразования Core-to-Core. Мы используем -dcore-lint постоянно; это добавляет около 5% к времени компиляции.

Почему у меня произошла ошибка линковки?

Если компоновщик жалуется на то, что не находит _<something>_fast, значит, что-то не так: вы, вероятно, не скомпилировали модули в правильном порядке зависимостей.

«Правильный ли этот номер строки?»

В этом плане GHC обычно работает хорошо, особенно если вы «разрешаете» отклонения на одну или две строки. В случае объявления класса или экземпляра, номер строки может указывать только на объявление, а не на конкретный метод.

Пожалуйста, сообщайте об ошибках номеров строк, которые вы считаете особенно неудобными.

10.2. Когда ваша программа делает «неправильные» вещи

(За советами по поводу слишком медленных или потребляющих много памяти программ Haskell, пожалуйста, обратитесь к Подсказкам).

«Помогите! Моя программа зависла!»

(например, «ошибка сегментации» или «выгружен core») ошибка сегментации

Если в вашей программе нет внешних вызовов и нет вызовов известных небезопасных функций (таких как unsafePerformIO), то сбой всегда является ОШИБКОЙ в системе GHC, за исключением одного случая: если ваша программа состоит из нескольких модулей, каждый модуль должен быть скомпилирован после всех модулей, от которых он зависит (если вы не используете .hi-boot файлы, в этом случае они должны быть корректны относительно исходного кода модуля).

Например, если интерфейс неправильно описывает тип импортированного значения, то GHC может сгенерировать некорректный код для импортирующего модуля. Это относится и к препроцессорным директивам внутри интерфейсов! Если препроцессорная директива ложная (например, относительно «арности» значения), может получиться некорректный код. Кроме того, арности могут изменяться даже если типы не изменяются.

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

Полезный вариант, который предупредит вас об изменениях интерфейсов, — -ddump-hi-diffs вариант. Он запустит diff на изменённом файле интерфейса, до и после, по мере необходимости.

Если вы используете make, GHC может автоматически сгенерировать зависимости, необходимые для обеспечения того, что каждый модуль действительно обновлён относительно его импортированных интерфейсов. Пожалуйста, см. Генерация зависимостей.

Если вы дошли до последней компиляции перед отчётом об ошибке, мы рекомендуем добавить -dcore-lint вариант (для дополнительной проверки) в параметры компиляции.

Итак, прежде чем отправлять отчёт об ошибке из-за выгрузки core, вы, вероятно, должны:

% rm *.o        # scrub your object files
% make my_prog  # re-make your program; use -ddump-hi-diffs to highlight changes;
                # as mentioned above, use -dcore-lint to be more paranoid
% ./my_prog ... # retry...

Конечно, если в вашей программе есть внешние вызовы, то все правила нарушены, потому что вы можете испортить кучу, стек или что угодно.

«Моя программа получила «отсутствующий» аргумент.»

Это определённо вызвано ошибкой в GHC. Пожалуйста, сообщите об этом (см. Отправка отчётов об ошибках в GHC).

«В чём дело с этой арифметической (или плавающей точкой) ошибкой?»

Int, Float, и Double арифметика не проверяется. Переполнения, недополнения и потеря точности либо не сообщаются, либо сообщаются как исключение операционной системой (в зависимости от платформы). Деление на ноль может вызвать незахваченное исключение (пожалуйста, сообщите об этом, если это произошло).