.. .. _release-8-0-2: Release notes for version 8.0.2 =============================== .. _release-8-0-2: バージョン 8.0.2 のリリースノート ================================= .. The significant changes to the various parts of the compiler are listed in the following sections. There have also been numerous bug fixes and performance improvements over the 8.0.1 release. コンパイラのさまざまな重大な変更箇所については次節以降で網羅します． 8.0.1 にあった大量のバグの修正と性能改善を行いました． .. .. warning:: Only Cabal versions 1.24 and newer will function properly with this release. (see :ghc-ticket:`11558`). Consequently it will likely be necessary to recompile ``cabal-install`` before installing new packages. The reason for this is a change in how packages are identified in GHC 8.0. While previous versions of Cabal identified packages to GHC with a package key (with GHC's :ghc-flag:`-this-package-key` argument), GHC 8.0 and later uses installed package IDs in place of package keys. .. warning:: このリリースでは，Cabal のバージョン 1.24 以降でないと正しく機能しません(:ghc-ticket:`11558` 参照)． したがって，新しいパッケージをインストールする前に ``cabal-install`` を再コンパイルする必要があります． 理由は GHC 8.0 でパッケージの識別方法が変更になったからです． Cabal の以前のバージョンでは，GHCのパッケージを(GHC の :ghc-flag:`-this-package-key` 引数を使って) パッケージキーで識別していましたが，GHC 8.0 以降ではパッケージキーの代りにインストール済みパッケージ ID を使います． .. .. note:: Users compiling GHC on Mac OS X with XCode 7.3 will need to tell the build system to use the ``nm-classic`` command instead of Apple's new ``nm`` implementation as the latter breaks POSIX compliance (see :ghc-ticket:`11744`). This can be done by passing something like ``--with-nm=$(xcrun --find nm-classic)`` to ``configure``. .. note:: ユーザーが Mac OS X で XCode 7.3 を使って GHC をコンパイルするには，ビルドシステムに Apple の新しい ``nm`` コマンドではなく ``nm-classic`` コマンドを使うように指示しなければなりません． 新しい ``nm`` コマンドは POSIX の規約を破っているからです． (:ghc-ticket:`11744` 参照)． 指示は ``configure`` コマンドに ``--with-nm=$(xcrun --find nm-classic)`` のように指定します． .. Highlights ---------- ハイライト ---------- .. The highlights, since the 8.0.1 release, are: 8.0.1 のリリースからの変更のハイライトは以下のとおりです． .. - Compatibility fixes with macOS Sierra and recent Linux distributions. - macOS Sierra および，最近の Linux のディストリビューションでの互換性を修正 .. - Many, many bug fixes. - たくさん，たくさんのバグ修正 .. - A bug has been fixed that caused standalone derived ``Ix`` instances to fail for GADTs with exactly one constructor (:ghc-ticket:`12583`). - 単一構成子をもつ GADT を ``Ix`` のインスタンスとしてスタンドアロン導出しようとすると失敗するバグを修正(:ghc-ticket:`12583`)． .. - Interface files produced by GHC should now be deterministic. - GHCが生成するインターフェイスファイルは決定的でなければならなくなりました． .. Full details ------------ 詳細 ---- .. Language ~~~~~~~~ 言語拡張 ~~~~~~~~ .. - A bug has been fixed that caused derived ``Show`` instances to fail in the presence of :ghc-flag:`-XRebindableSyntax` and :ghc-flag:`-XOverloadedStrings` (:ghc-ticket:`12688`). - :ghc-flag:`-XRebindableSyntax` および :ghc-flag:`-XOverloadedStrings` が指定されている場合に ``Show`` インスタンスの導出に失敗するバグを修正 (:ghc-ticket:`12688`)． .. - GHC is now a bit more strict in typechecking code generated by :ghc-flag:`-XGeneralizedNewtypeDeriving`. For example, GHC will now reject this program: :: class C m where foo :: C m => m () newtype N m a = N (m a) deriving C -- This is now an error This is in contrast to GHC 8.0.1 and earlier, which would accept this code. To fix this code, simply remove the ``C m`` constraint from ``foo``, as it is wholly unnecessary: :: class C m where foo :: m () - :ghc-flag:`-XGeneralizedNewtypeDeriving` を指定することで生成する型検査コードがより厳格になりました． たとえば，以下のプログラムは GHC が拒絶します． :: class C m where foo :: C m => m () newtype N m a = N (m a) deriving C -- This is now an error GHC 8.0.1 以前はこのコードは通っていました． 単に ``foo`` にある全く不要の ``C m`` 制約を削除するだけで，このコードは修正できます． :: class C m where foo :: m () .. - Some programs using :ghc-flag:`-XDefaultSignatures` that incorrectly type-checked in GHC 8.0.1 are now rejected by GHC 8.0.2. Here is a characteristic example: :: class Monad m => MonadSupply m where fresh :: m Integer default fresh :: (MonadTrans t, MonadSupply m) => t m Integer fresh = lift freshが instance MonadSupply m => MonadSupply (IdentityT m) Note that the ``m`` in the default type signature is being used in a completely different way than the ``m`` in the non-default signature! We can fix this (in a backwards-compatible way) like so: :: class Monad m => MonadSupply m where fresh :: m Integer default fresh :: (MonadTrans t, MonadSupply m', m ~ t m') => m Integer -- Same 'm Integer' after the '=>' fresh = lift fresh - :ghc-flag:`-XDefaultSignatures` を使ってプログラムで GHC 8.0.1 では正しく型検査ができないものがありましたが， GHC 8.0.2 はこれをリジェクトするようになりました． それを示す例を以下に挙げます． :: class Monad m => MonadSupply m where fresh :: m Integer default fresh :: (MonadTrans t, MonadSupply m) => t m Integer fresh = lift fresh instance MonadSupply m => MonadSupply (IdentityT m) デフォルトのタイプシグネチャの ``m`` とデフォルトのタイプシグネチャではない部分の ``m`` は全く違う使い方です． これを(後方互換性のある方法で)修正するには以下のように書きます． :: class Monad m => MonadSupply m where fresh :: m Integer default fresh :: (MonadTrans t, MonadSupply m', m ~ t m') => m Integer -- Same 'm Integer' after the '=>' fresh = lift fresh .. - Some programs which combine default type class method implementations and overlapping instances may now fail to type-check. Here is an example: :: class Foo a where foo :: a -> [a] foo _ = [] instance Foo a instance Foo Int The problem is that the overlapping ``Foo Int`` instance is not explicitly marked as overlapping. To fix this, simply add an ``OVERLAPPING`` pragma: :: instance {-# OVERLAPPING #-} Foo Int - デフォルトの型クラスメソッド実装とオーバーラッピングインスタンスを組み合わせているプログラムの一部は 型検査に失敗するようになりました．以下はその例です． :: class Foo a where foo :: a -> [a] foo _ = [] instance Foo a instance Foo Int 問題はオーバーラッピングインスタンス ``Foo Int`` に明示的にオーバーラッピングを示すマークが付いていないことです． これを修正するには，単に ``OVERLAPPING`` プラグマを加えるだけです． :: instance {-# OVERLAPPING #-} Foo Int .. - GHC now adheres more closely to the Haskell 2010 Report with respect to defaulting rules. As a result, GHC will now reject some defaulting rules which GHC 8.0.1 and earlier would accept. For example, this is now rejected :: module Foo where default (Bool) because when the :ghc-flag:`-XExtendedDefaultRules` extension is not enabled, defaulting rules only work for the ``Num`` class, of which ``Bool`` is not an instance. To make GHC accept the above program, simply enable the :ghc-flag:`-XExtendedDefaultRules` extension. - GHC はデフォルト規則に関して，より Haskell 2010 Report に近くなりました． その結果，GHC はバージョン 8.0.1 以前には受け入れていたいくつかのデフォルト規則を拒絶するようになりました． たとえば，以下は拒絶されます． :: module Foo where default (Bool) その理由は :ghc-flag:`-XExtendedDefaultRules` 拡張が有効になっていなければ， デフォルト規則は ``Num`` クラスに対してしか効きませんが ``Bool`` は ``Num`` のインスタンスではないからです． GHC がこれを受け入れるようにするには :ghc-flag:`-XExtendedDefaultRules` 拡張を有効にするだけです． .. Compiler ~~~~~~~~ コンパイラ ~~~~~~~~~~ .. - A compiler bug present in 8.0.1 resulting in undefined reference errors while compiling some packages has been fixed. (see :ghc-ticket:`12076`). - 8.0.1 にあった，いくつかのパッケージをコンパイル中に未定義参照エラーになるというバグを修正しました (:ghc-ticket:`12076` 参照)． .. - A code generator bug which resulted in segmentation faults in compiled programs has been fixed (see :ghc-ticket:`12757`). - コンパイル済みのプログラムでセグメンテーションフォルトがでるというコード生成器のバグを修正しました (ghc-ticket:`12757` 参照)． .. - GHC now supports systems whose C compiler produces position-independent executables by default. (see :ghc-ticket:`12579`). - GHC はデフォルトで，位置独立実行可能コードを生成する C コンパイラシステムをサポートするようになりました (:ghc-ticket:`12579` 参照)． .. - GHC can now be built on systems which use the ``gold`` linker by default (see :ghc-ticket:`12816`). - GHC はデフォルトで ``gold`` リンカを使うシステムでビルドできるようになりました (:ghc-ticket:`12816` 参照)． .. - GHC now reliably runs on macOS Sierra systems. Sierra introduced a linker limitation which GHC occassionally surpassed when compiling programs with many package dependencies. (see :ghc-ticket:`12479`). - GHC は macOS Sierra でちゃんと走るようになりました． Sierra が導入したリンカの制限を，大量のパッケージ依存があるプログラムをコンパイルするときに GHC が超えてしまうことがありました(:ghc-ticket:`12479` 参照)． .. - The :ghc-flag:`-Wredundant-constraints` flag has been removed from the :ghc-flag:`-Wall` flag set (see :ghc-ticket:`10635`). - :ghc-flag:`-Wredundant-constraints` フラグを :ghc-flag:`-Wall` フラグ集合から削除しました (:ghc-ticket:`10635`)． .. - Added :ghc-flag:`-fdefer-out-of-scope-variables`, which converts out-of-scope variable errors into warnings. - :ghc-flag:`-fdefer-out-of-scope-variables` フラグを追加しました． このフラグは範囲外変数エラーを警告に変えます． .. - The RTS :ghc-flag:`-xb` now reads the base heap address in any base, defaulting to decimal, hexadecimal if the address starts with ``0x``, and octal if the address starts with ``0``. - RTS の :ghc-flag:`-xb` はベースのヒープアドレスを任意の基数で読むようになりました． デフォルトでは10進，``0x`` ではじまるアドレスは16進 ``0`` ではじまるアドレスなら8進として読みます． .. - Due to an oversight in GHC 8.0.1, the value of the preprocessor macro ``__GLASGOW_HASKELL_LLVM__``, which exposes the LLVM version used by GHC, was no longer an integer. This value is now turned into an integer again, but the formatting is changed to be in line with ``__GLASGOW_HASKELL__`` (:ghc-ticket:`12628`). - とある見落としのせいで，GHC 8.0.1 では，GHCが使う LLVM のバージョンを表すプリプロセッサマクロ ``__GLASGOW_HASKELL_LLVM__`` の値が整数でなくなっていました． この値を整数に戻しました．ただし，フォーマットは ``__GLASGOW_HASKELL__`` のやりかたに沿ったものに変更しました (:ghc-ticket:`12628`)． .. - Parallel programs should be significantly more reliable on platforms with weak memory consistency guarantees (:ghc-ticket:`12469`) - ウィークメモリコンシステンシを保証するプラットフォーム上の並列プログラムの信頼性が大幅に向上しました (:ghc-ticket:`12469`)． .. - Interface files should now be bit-wise identical for a given build. (:ghc-ticket:`4012`) - 所定のビルドでは，インターフェイスファイルはビット単位で同一になるはずです (:ghc-ticket:`4012`)． .. - Nearly two-hundred more bugs. See `Trac `_ for a complete list. - 200を超えるバグを修正しました． `Trac `_ がその一覧です． .. Runtime system ~~~~~~~~~~~~~~ ランタイムシステム ~~~~~~~~~~~~~~~~~~ .. - The Runtime linker on Windows is once again recognizing POSIX functions under their "deprecated" name. e.g. "strdup" will now be recognized and internally forwarded to "_strdup". If you have existing code already using the correct names (e.g. _strdup) then this will just continue to work and no change is needed. For more information about how the forwarding is done please see `MSDN `_ . This should now introduce the same behavior both compiled and interpreted. (see :ghc-ticket:`12497`). - Windows 上のランタイムリンカは，再び「非推奨」名のPOSIX関数を識別するようになりました． たとえば strdup で識別して内部的には _strdup に転送します． 既存のコードで正しい名前を(たとえば _strdup)使っている場合，それはそのままで変更する必要はありません． この転送がどのように行われてりうかの詳細については `MSDN `_ を参照してください． これでコンパイル済みのコードとインタプリタを通したコードの振る舞いは同じになるはずです (:ghc-ticket:`12497` 参照)． .. - Profiles from the cost-center profiler now provide source span information. (see :ghc-ticket:`11543`). - コスト集約点プロファイラが出力するプロファイルにソース位置情報が含まれるようになりました (see :ghc-ticket:`11543`)． .. - The number of threads used for garbage collection is now configurable independently from the number of capabilities with the new :ghc-flag:`-qn` flag. - 新しい :ghc-flag:`-qn` フラグを使えば，可能なスレッド数とは独立して， ガーベッジコレクションに使うスレッドの数を設定できます． .. - The runtime system should now wake-up less often with large capability counts - 可能なスレッド数が大きいときのランタイムシステムの起動頻度が少くなりました． .. - The runtime system is now a more efficient in handling programs with many bound threads. (:ghc-ticket:`12419`) - ランタイムシステムがたくさんのスレッドに割り当てられたプログラムをより効率よく ハンドリングできるようになりました(:ghc-ticket:`12419`)． .. - A number of runtime system bugs which could result in crashes (see :ghc-ticket:`12728`, :ghc-ticket:`10860`, :ghc-ticket:`12019`, :ghc-ticket:`11978`, :ghc-ticket:`12038`, :ghc-ticket:`12208`) - クラッシュにつながる可能性のあったランタイムシステムのバグをいくつも修正しました (詳細は :ghc-ticket:`12728`, :ghc-ticket:`10860`, :ghc-ticket:`12019`, :ghc-ticket:`11978`, :ghc-ticket:`12038`, :ghc-ticket:`12208` 参照)． .. Template Haskell ~~~~~~~~~~~~~~~~ Template Haskell ~~~~~~~~~~~~~~~~ .. - ``addModFinalizer`` now exposes the local typing environment at the splice point. This allows ``reify`` to see local and top-level definitions in the current declaration group when used as in .. code-block:: none f x = $(addModFinalizer (reify 'x >>= runIO . print) >> [| x |]) - ``addModFinalizer`` は当該のスプライスポイントにおけるローカル型付け環境を表すようになりました． これにより以下のように ``reify`` から現在の宣言グループにおけるローカルおよびトップレベルの定義が見えるようになります． .. code-block:: none f x = $(addModFinalizer (reify 'x >>= runIO . print) >> [| x |]) .. ``ghc`` library ~~~~~~~~~~~~~~~ ``ghc`` library ~~~~~~~~~~~~~~~ .. - Accessors are now exposed for ``ErrUtils.ErrMsg`` and ``ErrUtils.ErrDoc``. - ``ErrUtils.ErrMsg`` および ``ErrUtils.ErrDoc`` のアクセサをエクスポートしました． .. - There is now a ``createIservProcessHook`` to allow API users to redirect the ``stdout`` and ``stderr`` handles. - API ユーザが ``createIservProcessHook`` を使って ``stdout`` および ``stderr`` ハンドルをリダイレクトできるようになりました．