Re-layout validate script
[ghc.git] / docs / users_guide / bugs.rst
1 .. _bugs-and-infelicities:
2
3 Known bugs and infelicities
4 ===========================
5
6 .. _vs-Haskell-defn:
7
8 Haskell standards vs. Glasgow Haskell: language non-compliance
9 --------------------------------------------------------------
10
11 .. index::
12    single: GHC vs the Haskell standards
13    single: Haskell standards vs GHC
14
15 This section lists Glasgow Haskell infelicities in its implementation of
16 Haskell 98 and Haskell 2010. See also the “when things go wrong” section
17 (:ref:`wrong`) for information about crashes, space leaks, and other
18 undesirable phenomena.
19
20 The limitations here are listed in Haskell Report order (roughly).
21
22 .. _haskell-standards-divergence:
23
24 Divergence from Haskell 98 and Haskell 2010
25 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
26
27 By default, GHC mainly aims to behave (mostly) like a Haskell 2010
28 compiler, although you can tell it to try to behave like a particular
29 version of the language with the :extension:`Haskell98` and
30 :extension:`Haskell2010` flags. The known deviations from the standards are
31 described below. Unless otherwise stated, the deviation applies in Haskell 98,
32 Haskell 2010 and the default modes.
33
34 .. _infelicities-lexical:
35
36 Lexical syntax
37 ^^^^^^^^^^^^^^
38
39 -  Certain lexical rules regarding qualified identifiers are slightly
40    different in GHC compared to the Haskell report. When you have
41    ⟨module⟩\ ``.``\ ⟨reservedop⟩, such as ``M.\``, GHC will interpret it
42    as a single qualified operator rather than the two lexemes ``M`` and
43    ``.\``.
44
45 -  ``forall`` is always a reserved keyword at the type level, contrary
46    to the Haskell Report, which allows type variables to be named ``forall``.
47    Note that this does not imply that GHC always enables the
48    :extension:`ExplicitForAll` extension. Even without this extension enabled,
49    reserving ``forall`` as a keyword has significance. For instance, GHC will
50    not parse the type signature ``foo :: forall x``.
51
52 -  The ``(!)`` operator, when written in prefix form (preceded by whitespace
53    and not followed by whitespace, as in ``f !x = ...``), is interpreted as a
54    bang pattern, contrary to the Haskell Report, which prescribes to treat ``!``
55    as an operator regardless of surrounding whitespace. Note that this does not
56    imply that GHC always enables :extension:`BangPatterns`. Without the
57    extension, GHC will issue a parse error on ``f !x``, asking to enable the
58    extension.
59
60 -  Irrefutable patterns must be written in prefix form::
61
62      f ~a ~b = ...    -- accepted by both GHC and the Haskell Report
63      f ~ a ~ b = ...  -- accepted by the Haskell Report but not GHC
64
65    When written in non-prefix form, ``(~)`` is treated by GHC as a regular
66    infix operator.
67
68    See `GHC Proposal #229 <https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0229-whitespace-bang-patterns.rst>`__
69    for the precise rules.
70
71 -  Strictness annotations in data declarations must be written in prefix form::
72
73      data T = MkT !Int   -- accepted by both GHC and the Haskell Report
74      data T = MkT ! Int  -- accepted by the Haskell Report but not GHC
75
76    See `GHC Proposal #229 <https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0229-whitespace-bang-patterns.rst>`__
77    for the precise rules.
78
79 -  As-patterns must not be surrounded by whitespace::
80
81      f p@(x, y, z) = ...    -- accepted by both GHC and the Haskell Report
82      f p @ (x, y, z) = ...  -- accepted by the Haskell Report but not GHC
83
84    When surrounded by whitespace, ``(@)`` is treated by GHC as a regular infix
85    operator.
86
87    See `GHC Proposal #229 <https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0229-whitespace-bang-patterns.rst>`__
88    for the precise rules.
89
90
91 .. _infelicities-syntax:
92
93 Context-free syntax
94 ^^^^^^^^^^^^^^^^^^^
95
96 -  In Haskell 98 mode and by default (but not in Haskell 2010 mode), GHC
97    is a little less strict about the layout rule when used in ``do``
98    expressions. Specifically, the restriction that "a nested context
99    must be indented further to the right than the enclosing context" is
100    relaxed to allow the nested context to be at the same level as the
101    enclosing context, if the enclosing context is a ``do`` expression.
102
103    For example, the following code is accepted by GHC: ::
104
105        main = do args <- getArgs
106                  if null args then return [] else do
107                  ps <- mapM process args
108                  mapM print ps
109
110    This behaviour is controlled by the :extension:`NondecreasingIndentation`
111    extension.
112
113 .. extension:: NondecreasingIndentation
114     :shortdesc: Allow nested contexts to be at the same indentation level as
115       its enclosing context.
116
117     Allow nested contexts to be at the same indentation level as
118     its enclosing context.
119
120 -  GHC doesn't do the fixity resolution in expressions during parsing as
121    required by Haskell 98 (but not by Haskell 2010). For example,
122    according to the Haskell 98 report, the following expression is
123    legal: ::
124
125            let x = 42 in x == 42 == True
126
127    and parses as: ::
128
129            (let x = 42 in x == 42) == True
130
131    because according to the report, the ``let`` expression “extends as
132    far to the right as possible”. Since it can't extend past the second
133    equals sign without causing a parse error (``==`` is non-fix), the
134    ``let``\-expression must terminate there. GHC simply gobbles up the
135    whole expression, parsing like this: ::
136
137            (let x = 42 in x == 42 == True)
138
139 .. _infelicities-exprs-pats:
140
141 Expressions and patterns
142 ^^^^^^^^^^^^^^^^^^^^^^^^
143
144 In its default mode, GHC makes some programs slightly more defined than
145 they should be. For example, consider ::
146
147     f :: [a] -> b -> b
148     f [] = error "urk"
149     f (x:xs) = \v -> v
150
151     main = print (f [] `seq` True)
152
153 This should call ``error`` but actually prints ``True``. Reason: GHC
154 eta-expands ``f`` to
155
156 ::
157
158     f :: [a] -> b -> b
159     f []     v = error "urk"
160     f (x:xs) v = v
161
162 This improves efficiency slightly but significantly for most programs,
163 and is bad for only a few. To suppress this bogus "optimisation" use
164 ``-fpedantic-bottoms``.
165
166 .. _infelicities-decls:
167
168 Declarations and bindings
169 ^^^^^^^^^^^^^^^^^^^^^^^^^
170
171 In its default mode, GHC does not accept datatype contexts, as it has
172 been decided to remove them from the next version of the language
173 standard. This behaviour can be controlled with the ``DatatypeContexts``
174 extension. See :ref:`datatype-contexts`.
175
176 .. _infelicities-recursive-groups:
177
178 Typechecking of recursive binding groups
179 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
180
181 The Haskell Report specifies that a group of bindings (at top level, or
182 in a ``let`` or ``where``) should be sorted into strongly-connected
183 components, and then type-checked in dependency order
184 (`Haskell Report, Section
185 4.5.1 <http://www.haskell.org/onlinereport/decls.html#sect4.5.1>`__). As
186 each group is type-checked, any binders of the group that have an
187 explicit type signature are put in the type environment with the
188 specified polymorphic type, and all others are monomorphic until the
189 group is generalised (`Haskell Report, Section
190 4.5.2 <http://www.haskell.org/onlinereport/decls.html#sect4.5.2>`__).
191
192 Following a suggestion of Mark Jones, in his paper `Typing Haskell in
193 Haskell <https://web.cecs.pdx.edu/~mpj/thih/>`__, GHC implements a
194 more general scheme. In GHC *the dependency analysis ignores references to
195 variables that have an explicit type signature*. As a result of this refined
196 dependency analysis, the dependency groups are smaller, and more bindings will
197 typecheck. For example, consider: ::
198
199       f :: Eq a => a -> Bool
200       f x = (x == x) || g True || g "Yes"
201
202       g y = (y <= y) || f True
203
204 This is rejected by Haskell 98, but under Jones's scheme the definition
205 for ``g`` is typechecked first, separately from that for ``f``, because
206 the reference to ``f`` in ``g``\'s right hand side is ignored by the
207 dependency analysis. Then ``g``\'s type is generalised, to get ::
208
209       g :: Ord a => a -> Bool
210
211 Now, the definition for ``f`` is typechecked, with this type for ``g``
212 in the type environment.
213
214 The same refined dependency analysis also allows the type signatures of
215 mutually-recursive functions to have different contexts, something that is
216 illegal in Haskell 98 (Section 4.5.2, last sentence). GHC only insists that the
217 type signatures of a *refined* group have identical type signatures; in practice
218 this means that only variables bound by the same pattern binding must have the
219 same context. For example, this is fine: ::
220
221       f :: Eq a => a -> Bool
222       f x = (x == x) || g True
223
224       g :: Ord a => a -> Bool
225       g y = (y <= y) || f True
226
227 .. _infelicities-default-exports:
228
229 Default Module headers with -main-is
230 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
231
232 The Haskell2010 Report specifies in <https://www.haskell.org/onlinereport/haskell2010/haskellch5.html#x11-990005.1> that
233
234     "An abbreviated form of module, consisting only of the module body,
235      is permitted. If this is used, the header is assumed to be
236      `module Main(main) where`."
237
238 GHC's ``-main-is`` option can be used to change the name of the top-level entry
239 point from ``main`` to any other variable.  When compiling the main module and
240 ``-main-is`` has been used to rename the default entry point, GHC will also use
241 the alternate name in the default export list.
242
243 Consider the following program: ::
244
245     -- file: Main.hs
246     program :: IO ()
247     program = return ()
248
249 GHC will successfully compile this module with
250 ``ghc -main-is Main.program Main.hs``, because the default export list
251 will include ``program`` rather than ``main``, as the Haskell Report
252 typically requires.
253
254 This change only applies to the main module.  Other modules will still export
255 ``main`` from a default export list, regardless of the ``-main-is`` flag.
256 This allows use of ``-main-is`` with existing modules that export ``main`` via
257 a default export list, even when ``-main-is`` points to a different entry
258 point, as in this example (compiled with ``-main-is MainWrapper.program``). ::
259
260     -- file MainWrapper.hs
261     module MainWrapper where
262     import Main
263
264     program :: IO ()
265     program = putStrLn "Redirecting..." >> main
266
267     -- file Main.hs
268     main :: IO ()
269     main = putStrLn "I am main."
270
271 .. _infelicities-Modules:
272
273 Module system and interface files
274 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
275
276 GHC requires the use of ``hs-boot`` files to cut the recursive loops
277 among mutually recursive modules as described in
278 :ref:`mutual-recursion`. This more of an infelicity than a bug: the
279 Haskell Report says (`Section
280 5.7 <http://haskell.org/onlinereport/modules.html#sect5.7>`__)
281
282     "Depending on the Haskell implementation used, separate compilation of
283     mutually recursive modules may require that imported modules contain
284     additional information so that they may be referenced before they are
285     compiled. Explicit type signatures for all exported values may be
286     necessary to deal with mutual recursion. The precise details of separate
287     compilation are not defined by this Report."
288
289 .. _infelicities-numbers:
290
291 Numbers, basic types, and built-in classes
292 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
293
294 ``Num`` superclasses
295     The ``Num`` class does not have ``Show`` or ``Eq`` superclasses.
296
297
298     You can make code that works with both Haskell98/Haskell2010 and GHC
299     by:
300
301     -  Whenever you make a ``Num`` instance of a type, also make
302         ``Show`` and ``Eq`` instances, and
303
304     -  Whenever you give a function, instance or class a ``Num t``
305         constraint, also give it ``Show t`` and ``Eq t`` constraints.
306
307 ``Bits`` superclass
308     The ``Bits`` class does not have a ``Num`` superclass. It
309     therefore does not have default methods for the ``bit``, ``testBit``
310     and ``popCount`` methods.
311
312     You can make code that works with both Haskell 2010 and GHC by:
313
314     -  Whenever you make a ``Bits`` instance of a type, also make a
315         ``Num`` instance, and
316
317     -  Whenever you give a function, instance or class a ``Bits t``
318         constraint, also give it a ``Num t`` constraint, and
319
320     -  Always define the ``bit``, ``testBit`` and ``popCount`` methods
321         in ``Bits`` instances.
322
323 ``Read`` class methods
324     The ``Read`` class has two extra methods, ``readPrec`` and
325     ``readListPrec``, that are not found in the Haskell 2010 since they rely
326     on the ``ReadPrec`` data type, which requires the :extension:`RankNTypes`
327     extension. GHC also derives ``Read`` instances by implementing ``readPrec``
328     instead of ``readsPrec``, and relies on a default implementation of
329     ``readsPrec`` that is defined in terms of ``readPrec``. GHC adds these two
330     extra methods simply because ``ReadPrec`` is more efficient than ``ReadS``
331     (the type on which ``readsPrec`` is based).
332
333 ``Monad`` superclass
334     The ``Monad`` class has an ``Applicative`` superclass. You cannot write
335     ``Monad`` instances that work for GHC and also for a Haskell 2010
336     implementation that does not define ``Applicative``.
337
338 Extra instances
339     The following extra instances are defined: ::
340
341         instance Functor ((->) r)
342         instance Monad ((->) r)
343         instance Functor ((,) a)
344         instance Functor (Either a)
345         instance Monad (Either e)
346
347 Multiply-defined array elements not checked
348     This code fragment should elicit a fatal error, but it does not: ::
349
350         main = print (array (1,1) [(1,2), (1,3)])
351
352     GHC's implementation of ``array`` takes the value of an array slot
353     from the last (index,value) pair in the list, and does no checking
354     for duplicates. The reason for this is efficiency, pure and simple.
355
356 .. _infelicities-Prelude:
357
358 In ``Prelude`` support
359 ^^^^^^^^^^^^^^^^^^^^^^
360
361 ``splitAt`` semantics
362     ``Data.List.splitAt`` is more strict than specified in the Report.
363     Specifically, the Report specifies that ::
364
365        splitAt n xs = (take n xs, drop n xs)
366
367     which implies that ::
368
369        splitAt undefined undefined = (undefined, undefined)
370
371     but GHC's implementation is strict in its first argument, so ::
372
373        splitAt undefined [] = undefined
374
375 ``Show``\ ing records
376     The Haskell 2010 definition of ``Show`` stipulates that the rendered
377     string should only include parentheses which are necessary to unambiguously
378     parse the result. For historical reasons, ``Show`` instances derived by GHC
379     include parentheses around records despite the fact that record syntax
380     binds more tightly than function application; e.g., ::
381
382         data Hello = Hello { aField :: Int } deriving (Show)
383
384         -- GHC produces...
385         show (Just (Hello {aField=42})) == "Just (Hello {aField=42})"
386
387         -- whereas Haskell 2010 calls for...
388         show (Just (Hello {aField=42})) == "Just Hello {aField=42}"
389
390 ``Read``\ ing integers
391     GHC's implementation of the ``Read`` class for integral types
392     accepts hexadecimal and octal literals (the code in the Haskell 98
393     report doesn't). So, for example, ::
394
395         read "0xf00" :: Int
396
397     works in GHC.
398
399     A possible reason for this is that ``readLitChar`` accepts hex and
400     octal escapes, so it seems inconsistent not to do so for integers
401     too.
402
403 ``isAlpha``
404     The Haskell 98 definition of ``isAlpha`` is: ::
405
406         isAlpha c = isUpper c || isLower c
407
408     GHC's implementation diverges from the Haskell 98 definition in the
409     sense that Unicode alphabetic characters which are neither upper nor
410     lower case will still be identified as alphabetic by ``isAlpha``.
411
412 ``hGetContents``
413     Lazy I/O throws an exception if an error is encountered, in contrast
414     to the Haskell 98 spec which requires that errors are discarded (see
415     Section 21.2.2 of the Haskell 98 report). The exception thrown is
416     the usual IO exception that would be thrown if the failing IO
417     operation was performed in the IO monad, and can be caught by
418     ``System.IO.Error.catch`` or ``Control.Exception.catch``.
419
420 .. _infelicities-ffi:
421
422 The Foreign Function Interface
423 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
424
425 ``hs_init()``, ``hs_exit()``
426     The FFI spec requires the implementation to support re-initialising
427     itself after being shut down with ``hs_exit()``, but GHC does not
428     currently support that. See :ghc-ticket:`13693`.
429
430     .. index::
431         single: hs_init
432         single: hs_exit
433
434 .. _infelicities-operator-sections:
435
436 Operator sections
437 ^^^^^^^^^^^^^^^^^
438
439 The Haskell Report demands that, for infix operators ``%``, the following
440 identities hold:
441
442 ::
443
444     (% expr) = \x -> x % expr
445     (expr %) = \x -> expr % x
446
447 However, the second law is violated in the presence of undefined operators,
448
449 ::
450
451     (%) = error "urk"
452     (() %)         `seq` () -- urk
453     (\x -> () % x) `seq` () -- OK, result ()
454
455 The operator section is treated like function application of an undefined
456 function, while the lambda form is in WHNF that contains an application of an
457 undefined function.
458
459 .. _haskell-98-2010-undefined:
460
461 GHC's interpretation of undefined behaviour in Haskell 98 and Haskell 2010
462 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
463
464 This section documents GHC's take on various issues that are left
465 undefined or implementation specific in Haskell 98.
466
467 ``Char``
468     .. index::
469        single: Char; size of
470
471     Following the ISO-10646 standard, ``maxBound :: Char`` in GHC is
472     ``0x10FFFF``.
473
474 ``Int``
475     .. index::
476        single: Int; size of
477        single: fromInteger function
478        single: fromIntegral function
479
480     In GHC the ``Int`` type follows the size of an address on the host
481     architecture; in other words it holds 32 bits on a 32-bit machine,
482     and 64-bits on a 64-bit machine.
483
484     Arithmetic on ``Int`` is unchecked for overflow\ ``Int``, so
485     all operations on ``Int`` happen modulo 2\ :sup:`⟨n⟩` where ⟨n⟩ is
486     the size in bits of the ``Int`` type.
487
488     The ``fromInteger`` (and hence also ``fromIntegral``) is a special case when
489     converting to ``Int``. The value of ``fromIntegral x :: Int`` is
490     given by taking the lower ⟨n⟩ bits of ``(abs x)``, multiplied by the
491     sign of ``x`` (in 2's complement ⟨n⟩-bit arithmetic). This behaviour
492     was chosen so that for example writing ``0xffffffff :: Int``
493     preserves the bit-pattern in the resulting ``Int``.
494
495     Negative literals, such as ``-3``, are specified by (a careful
496     reading of) the Haskell Report as meaning
497     ``Prelude.negate (Prelude.fromInteger 3)``. So ``-2147483648`` means
498     ``negate (fromInteger 2147483648)``. Since ``fromInteger`` takes the
499     lower 32 bits of the representation,
500     ``fromInteger (2147483648::Integer)``, computed at type ``Int`` is
501     ``-2147483648::Int``. The ``negate`` operation then overflows, but
502     it is unchecked, so ``negate (-2147483648::Int)`` is just
503     ``-2147483648``. In short, one can write ``minBound::Int`` as a
504     literal with the expected meaning (but that is not in general
505     guaranteed).
506
507     The ``fromIntegral`` function also preserves bit-patterns when
508     converting between the sized integral types (``Int8``, ``Int16``,
509     ``Int32``, ``Int64`` and the unsigned ``Word`` variants), see the
510     modules ``Data.Int`` and ``Data.Word`` in the library documentation.
511
512 Unchecked floating-point arithmetic
513     Operations on ``Float`` and ``Double`` numbers are *unchecked* for
514     overflow, underflow, and other sad occurrences. (note, however, that
515     some architectures trap floating-point overflow and
516     loss-of-precision and report a floating-point exception, probably
517     terminating the program)
518
519     .. index::
520         single: floating-point exceptions.
521
522 Large tuple support
523     The Haskell Report only requires implementations to provide tuple
524     types and their accompanying standard instances up to size 15. GHC
525     limits the size of tuple types to 62 and provides instances of
526     ``Eq``, ``Ord``, ``Bounded``, ``Read``, and ``Show`` for tuples up
527     to size 15. However, ``Ix`` instances are provided only for tuples
528     up to size 5.
529
530 .. _bugs:
531
532 Known bugs or infelicities
533 --------------------------
534
535 The bug tracker lists bugs that have been reported in GHC but not yet
536 fixed: see the `GHC issue tracker <https://gitlab.haskell.org/ghc/ghc/issues>`__. In
537 addition to those, GHC also has the following known bugs or
538 infelicities. These bugs are more permanent; it is unlikely that any of
539 them will be fixed in the short term.
540
541 .. _bugs-ghc:
542
543 Bugs in GHC
544 ~~~~~~~~~~~
545
546 -  GHC's runtime system implements cooperative multitasking, with
547    context switching potentially occurring only when a program
548    allocates. This means that programs that do not allocate may never
549    context switch. This is especially true of programs using STM, which
550    may deadlock after observing inconsistent state. See :ghc-ticket:`367`
551    for further discussion.
552
553    If you are hit by this, you may want to compile the affected module
554    with :ghc-flag:`-fno-omit-yields <-fomit-yields>` (see :ref:`options-f`).
555    This flag ensures that yield points are inserted at every function entrypoint
556    (at the expense of a bit of performance).
557
558 -  GHC does not allow you to have a data type with a context that
559    mentions type variables that are not data type parameters. For
560    example:
561
562    ::
563
564          data C a b => T a = MkT a
565
566    so that ``MkT``\'s type is
567
568    ::
569
570          MkT :: forall a b. C a b => a -> T a
571
572    In principle, with a suitable class declaration with a functional
573    dependency, it's possible that this type is not ambiguous; but GHC
574    nevertheless rejects it. The type variables mentioned in the context
575    of the data type declaration must be among the type parameters of the
576    data type.
577
578 -  GHC's inliner can be persuaded into non-termination using the
579    standard way to encode recursion via a data type:
580
581    ::
582
583          data U = MkU (U -> Bool)
584
585          russel :: U -> Bool
586          russel u@(MkU p) = not $ p u
587
588          x :: Bool
589          x = russel (MkU russel)
590
591    The non-termination is reported like this:
592
593    .. code-block:: none
594
595        ghc: panic! (the 'impossible' happened)
596          (GHC version 8.2.1 for x86_64-unknown-linux):
597            Simplifier ticks exhausted
598          When trying UnfoldingDone x_alB
599          To increase the limit, use -fsimpl-tick-factor=N (default 100)
600
601    with the panic being reported no matter how high a
602    :ghc-flag:`-fsimpl-tick-factor <-fsimpl-tick-factor=⟨n⟩>` you supply.
603
604    We have never found another class of programs, other than this
605    contrived one, that makes GHC diverge, and fixing the problem would
606    impose an extra overhead on every compilation. So the bug remains
607    un-fixed. There is more background in `Secrets of the GHC
608    inliner <http://research.microsoft.com/~simonpj/Papers/inlining/>`__.
609
610 -  On 32-bit x86 platforms when using the native code generator, the
611    :ghc-flag:`-fexcess-precision` option is always on.
612    This means that floating-point calculations are non-deterministic,
613    because depending on how the program is compiled (optimisation
614    settings, for example), certain calculations might be done at 80-bit
615    precision instead of the intended 32-bit or 64-bit precision.
616    Floating-point results may differ when optimisation is turned on. In
617    the worst case, referential transparency is violated, because for
618    example ``let x = E1 in E2`` can evaluate to a different value than
619    ``E2[E1/x]``.
620
621    .. index::
622       single: -msse2 option
623
624    One workaround is to use the :ghc-flag:`-msse2` option (see
625    :ref:`options-platform`), which generates code to use the SSE2
626    instruction set instead of the x87 instruction set. SSE2 code uses
627    the correct precision for all floating-point operations, and so gives
628    deterministic results. However, note that this only works with
629    processors that support SSE2 (Intel Pentium 4 or AMD Athlon 64 and
630    later), which is why the option is not enabled by default. The
631    libraries that come with GHC are probably built without this option,
632    unless you built GHC yourself.
633
634 -  The :ghc-flag:`state hack <-fno-state-hack>` optimization can result in
635    non-obvious changes in evaluation ordering which may hide exceptions, even
636    with :ghc-flag:`-fpedantic-bottoms` (see, e.g., :ghc-ticket:`7411`). For
637    instance, ::
638
639      import Control.Exception
640      import Control.DeepSeq
641      main = do
642          evaluate (('a' : undefined) `deepseq` return () :: IO ())
643          putStrLn "Hello"
644
645    Compiling this program with ``-O`` results in ``Hello`` to be printed,
646    despite the fact that ``evaluate`` should have bottomed. Compiling
647    with ``-O -fno-state-hack`` results in the exception one would expect.
648
649 -  Programs compiled with :ghc-flag:`-fdefer-type-errors` may fail a bit
650    more eagerly than one might expect. For instance, ::
651
652      {-# OPTIONS_GHC -fdefer-type-errors #-}
653      main = do
654        putStrLn "Hi there."
655        putStrLn True
656
657    Will emit no output, despite the fact that the ill-typed term appears
658    after the well-typed ``putStrLn "Hi there."``. See :ghc-ticket:`11197`.
659
660 -  Despite appearances ``*`` and ``Constraint`` aren't really distinct kinds
661    in the compiler's internal representation and can be unified producing
662    unexpected results. See :ghc-ticket:`11715` for one example.
663
664 -  Because of a toolchain limitation we are unable to support full Unicode paths
665    on Windows. On Windows we support up to Latin-1. See :ghc-ticket:`12971` for more.
666
667 .. _bugs-ghci:
668
669 Bugs in GHCi (the interactive GHC)
670 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
671
672 -  GHCi does not respect the ``default`` declaration in the module whose
673    scope you are in. Instead, for expressions typed at the command line,
674    you always get the default default-type behaviour; that is,
675    ``default(Int,Double)``.
676
677    It would be better for GHCi to record what the default settings in
678    each module are, and use those of the 'current' module (whatever that
679    is).
680
681 -  On Windows, there's a GNU ld/BFD bug whereby it emits bogus PE object
682    files that have more than 0xffff relocations. When GHCi tries to load
683    a package affected by this bug, you get an error message of the form
684
685    .. code-block:: none
686
687        Loading package javavm ... linking ... WARNING: Overflown relocation field (# relocs found: 30765)
688
689    The last time we looked, this bug still wasn't fixed in the BFD
690    codebase, and there wasn't any noticeable interest in fixing it when
691    we reported the bug back in 2001 or so.
692
693    The workaround is to split up the .o files that make up your package
694    into two or more .o's, along the lines of how the ``base`` package does
695    it.