1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
|
.. _release-8-0-2:
Release notes for version 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.
.. 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.
.. 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``.
Highlights
----------
The highlights, since the 8.0.1 release, are:
- Compatibility fixes with macOS Sierra and recent Linux distributions.
- 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`).
- Interface files produced by GHC should now be deterministic.
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 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 ()
- 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
- 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
- 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.
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`).
- A code generator bug which resulted in segmentation faults in compiled
programs has been fixed (see :ghc-ticket:`12757`).
- GHC now supports systems whose C compiler produces position-independent
executables by default. (see :ghc-ticket:`12579`).
- GHC can now be built on systems which use the ``gold`` linker by default
(see :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`).
- The :ghc-flag:`-Wredundant-constraints` flag has been removed from the
:ghc-flag:`-Wall` flag set (see :ghc-ticket:`10635`).
- Added :ghc-flag:`-fdefer-out-of-scope-variables`, which converts
out-of-scope variable errors into warnings.
- 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``.
- 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`).
- Parallel programs should be significantly more reliable on platforms with weak
memory consistency guarantees (:ghc-ticket:`12469`)
- Interface files should now be bit-wise identical for a given build.
(:ghc-ticket:`4012`)
- Nearly two-hundred more bugs. See `Trac
<https://ghc.haskell.org/trac/ghc/query?status=closed&milestone=8.0.2&col=id&col=summary&col=status&col=type&col=priority&col=milestone&col=component&order=priority>`_
for a complete list.
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 <https://msdn.microsoft.com/en-us/library/ms235384.aspx>`_ . This should now introduce the same
behavior both compiled and interpreted. (see :ghc-ticket:`12497`).
- Profiles from the cost-center profiler now provide source span information.
(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.
- 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`)
- 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`)
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 |])
``ghc`` library
~~~~~~~~~~~~~~~
- Accessors are now exposed for ``ErrUtils.ErrMsg`` and ``ErrUtils.ErrDoc``.
- There is now a ``createIservProcessHook`` to allow API users to redirect the
``stdout`` and ``stderr`` handles.
|
