13. Что делать, если что-то пошло не так

Если у вас все еще есть проблема после обращения к этому разделу, возможно, вы обнаружили ошибку — пожалуйста, сообщите о ней! См. Отчет об ошибках в GHC для получения подробной информации о том, как сообщить об ошибке, и о том, что мы хотели бы узнать о вашей ошибке. Если вы сомневаетесь, отправьте отчет — мы любим письма от раздраженных пользователей :-!

(Стандарты Haskell против Glasgow Haskell: несоблюдение языка, в котором описываются недостатки Glasgow Haskell по сравнению с определением языка Haskell, также может быть интересным.)

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

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

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

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

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

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

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

Sensitivity to .hi interface files

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

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

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

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

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

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

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

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

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

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

(Для советов о чрезмерно медленных или требующих много памяти Haskell программах, пожалуйста, см. Советы по: быстрее, эффективнее, компактнее, экономнее).

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

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

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

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

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

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

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

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

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

% 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 арифметика не проверяется. Переполнения, недополнения и потеря точности либо игнорируются, либо сообщаются как исключение операционной системой (в зависимости от платформы). Деление на ноль может вызвать неперехваченное исключение (пожалуйста, сообщите об этом, если это происходит).