December 2018 - ghc-tickets

[GHC] #15858: Enabling a pure Plugin with existing build output never triggers recompilation
by GHC 12 Dec '18

12 Dec '18

#15858: Enabling a pure Plugin with existing build output never triggers recompilation -------------------------------------+------------------------------------- Reporter: DanielG | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider the following compilation session: {{{ $ ghc -fplugin ImpurePlugin Foo.hs <Compiles Foo.hs> $ ghc Foo.hs }}} where ImpurePlugin is a `Plugin` which returns `ForceRecompile` in `pluginRecompile`. The second invocation of GHC doesn't recompile even though `ImpurePlugin` could have changed the generated build output which would now be out of date. The same thing happens when switching from an impure/fingerprinted plugin to a pure plugin. The problem is that `pluginRecompileToRecompileRequired` just assumes no compilation is required when the current plugin stack is pure, that is either only pure plugins or no plugins at all are registered: {{{ pluginRecompileToRecompileRequired :: Fingerprint -> PluginRecompile -> RecompileRequired pluginRecompileToRecompileRequired old_fp pr = case pr of NoForceRecompile -> UpToDate ForceRecompile -> RecompBecause "Plugin forced recompilation" MaybeRecompile fp -> if fp == old_fp then UpToDate }}} note the `UpToDate` in the `NoForceRecompile` case. Furthermore I would argue that even switching from having no plugin at all active to having a pure plugin active should trigger recompilation, even though the plugin might be pure it could still choose to affect the build output after all. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15858> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #16037: memcpy test inexplicably failing
by GHC 12 Dec '18

12 Dec '18

#16037: memcpy test inexplicably failing -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Compiler | Version: 8.7 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I have started seeing failures in the `memcpy` test: {{{#!diff diff -uw "codeGen/should_gen_asm/memcpy.run/memcpy.asm.normalised" "codeGen/should_gen_asm/memcpy.run/memcpy.s.normalised" --- codeGen/should_gen_asm/memcpy.run/memcpy.asm.normalised 2018-12-11 23:13:18.763730758 -0500 +++ codeGen/should_gen_asm/memcpy.run/memcpy.s.normalised 2018-12-11 23:13:18.763730758 -0500 @@ -1,9 +1,9 @@ callMemcpy: +subq movq movq movl -subq -movl +xorl call memcpy addq jmp }}} The failures aren't themselves concerning; the new assembler is perfectly valid: {{{#!asm .section .text .align 8 .globl callMemcpy .type callMemcpy, @function callMemcpy: .Lc6: movl $1024,%eax subq $8,%rsp movq %rax,%rdx movq %rbx,%rdi movq %r14,%rsi xorl %eax,%eax call memcpy addq $8,%rsp jmp *(%rbp) .size callMemcpy, .-callMemcpy .section .note.GNU-stack,"",@progbits .ident "GHC 8.7.20181211" }}} However, I have no explanation for why this suddenly started happening. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16037> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #16025: Makefiles bundled with source distribution fail to build cross-compiler.
by GHC 12 Dec '18

12 Dec '18

#16025: Makefiles bundled with source distribution fail to build cross-compiler. -------------------------------------+------------------------------------- Reporter: vanessamchale | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.3 (make) | Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 | Type of failure: Building GHC (amd64) | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When trying to build a cross-compiler with GHC 8.6.3, I ran into the following: {{{ ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) ld: libraries/ghc-prim/dist-install/build/GHC/CString.o: Relocations in generic ELF (EM: 40) libraries/ghc-prim/dist-install/build/GHC/CString.o: error adding symbols: File in wrong format echo libraries/ghc-prim/dist-install/build/GHC/CString.o libraries/ghc- prim/dist-install/build/GHC/Classes.o libraries/ghc-prim/dist- install/build/GHC/Debug.o libraries/ghc-prim/dist- install/build/GHC/IntWord64.o libraries/ghc-prim/dist- install/build/GHC/Magic.o libraries/ghc-prim/dist- install/build/GHC/PrimopWrappers.o libraries/ghc-prim/dist- install/build/GHC/Tuple.o libraries/ghc-prim/dist- install/build/GHC/Types.o libraries/ghc-prim/dist- install/build/cbits/atomic.o libraries/ghc-prim/dist- install/build/cbits/bswap.o libraries/ghc-prim/dist- install/build/cbits/clz.o libraries/ghc-prim/dist- install/build/cbits/ctz.o libraries/ghc-prim/dist- install/build/cbits/debug.o libraries/ghc-prim/dist- install/build/cbits/longlong.o libraries/ghc-prim/dist- install/build/cbits/pdep.o libraries/ghc-prim/dist- install/build/cbits/pext.o libraries/ghc-prim/dist- install/build/cbits/popcnt.o libraries/ghc-prim/dist- install/build/cbits/word2float.o >> libraries/ghc-prim/dist- install/build/libHSghc-prim-0.5.3.a.contents libraries/ghc-prim/ghc.mk:4: recipe for target 'libraries/ghc-prim/dist- install/build/HSghc-prim-0.5.3.o' failed make[1]: *** [libraries/ghc-prim/dist-install/build/HSghc-prim-0.5.3.o] Error 1 make[1]: *** Waiting for unfinished jobs.... "arm-linux-gnueabihf-ar" q libraries/ghc-prim/dist-install/build /libHSghc-prim-0.5.3.a @libraries/ghc-prim/dist-install/build/libHSghc- prim-0.5.3.a.contents arm-linux-gnueabihf-ar: creating libraries/ghc-prim/dist-install/build /libHSghc-prim-0.5.3.a "rm" -f libraries/ghc-prim/dist-install/build/libHSghc- prim-0.5.3.a.contents Makefile:122: recipe for target 'all' failed make: *** [all] Error 2 It seems that this was due to an error in mk/config.mk, viz. LD_NO_GOLD = ld LD = arm-linux-gnueabihf-ld.gold NM = arm-linux-gnueabihf-nm AR = arm-linux-gnueabihf-ar OBJDUMP = arm-linux-gnueabihf-objdump }}} The variable {{{LD_NO_GOLD}}} should have the prefix {{{arm-linux- gnueabihf}}}. When I set {{{LD_NO_GOLD}}} to {{{arm-linux-gnueabihf-ld}}} manually, the build proceeds and works correctly. Let me know if you need any additional information. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16025> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #14551: GHCi ignores -XMonomorphismRestriction and -XNoExtendedDefaultRules
by GHC 12 Dec '18

12 Dec '18

#14551: GHCi ignores -XMonomorphismRestriction and -XNoExtendedDefaultRules -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Because of the way the GHCi defaults are applied, specifying `-XMonomorphismRestriction` or `-XNoExtendedDefaultRules` on the GHCi command line doesn't actually make those take effect at the interactive prompt. They get reset to their interactive defaults afterwards. This is rather surprising, and I think it should be fixed. One option is to dig through the parsed flags after setting the defaults to try to find these, but that sounds unpleasant. We're slowly accumulating hacks in this area, and it would be nice to find a better approach. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14551> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

Re: [GHC] #3379: GHC should use the standard binary package
by GHC 12 Dec '18

12 Dec '18

#3379: GHC should use the standard binary package -------------------------------------+------------------------------------- Reporter: igloo | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ulysses4ever): Oh, quite so, thank you Ben! I [https://gitlab.staging.haskell.org/ulysses4ever/ghc/commit/a73488e420de3f69… fixed it] and now GHC compiles. I ran the test suite and had one unexpected failure (which I did not see before the patch): {{{ Unexpected results from: TEST="T14052" SUMMARY for test run started at Wed Dec 12 14:54:05 2018 UTC 0:52:39 spent to go through 6713 total tests, which gave rise to 20813 test cases, of which 13674 were skipped 45 had missing libraries 6936 expected passes 157 expected failures 0 caused framework failures 0 caused framework warnings 0 unexpected passes 1 unexpected failures 0 unexpected stat failures Unexpected failures: perf/should_run/T14052.run T14052 [[Errno 2] No such file or directory: 'perf/should_run/T14052.run/T14052.stats'] (ghci) }}} This feels strange. What should be the right way to investigate it? (I'm not super comfortable with the test suite). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3379#comment:18> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #15656: Extend -Wall with incomplete-uni-patterns and incomplete-record-updates
by GHC 12 Dec '18

12 Dec '18

#15656: Extend -Wall with incomplete-uni-patterns and incomplete-record-updates -------------------------------------+------------------------------------- Reporter: ckoparkar | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Keywords: GHCProposal | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The [https://github.com/ghc-proposals/ghc-proposals/pull/71 proposal] has been accepted, and could be implemented. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15656> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #16041: Address warnings reported by -Wincomplete-uni-patterns and -Wincomplete-record-updates
by GHC 12 Dec '18

12 Dec '18

#16041: Address warnings reported by -Wincomplete-uni-patterns and -Wincomplete- record-updates -------------------------------------+------------------------------------- Reporter: ckoparkar | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #15656 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- While implementing the GHC proposal which adds these flags to {{{-Wall}}}, we suppressed a lot of warnings generated due to code that is considered ''unsafe'' per these flags. However, the proper way to fix this is to refine things so that these warnings go away. See https://ghc.haskell.org/trac/ghc/ticket/15656#comment:6 for more details. w -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16041> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #16027: Cannot use DefaultSignatures for TypeFamiles
by GHC 11 Dec '18

11 Dec '18

#16027: Cannot use DefaultSignatures for TypeFamiles -------------------------------------+------------------------------------- Reporter: Ericson2314 | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I'm surprised there wasn't a ticket for this. Maybe I just couldn't find it. In short, I want to do something like: {{{ class Monad m => MyMonad m where type AssociatedMonad m :: Type -> Type default type AssociatedMonad m :: (m ~ t m', MonadTrans t, MyMonad m') => Type -> Type type AssociatedMonad (t m') = t (AssociatedMonad m') fun :: Foo -> m () default fun :: (m ~ t m', MonadTrans t, MyMonad m') => Foo -> m () fun = lift . fun }}} The syntax is a bit weird, but I hope in the process of implementing constrained type families the syntax properly analogous to the term-level would shake itself out. The use-case, like the normal method original, is to assist with monad transformer boilerplate. {{{MonadTrans}}} wouldn't be enough, but {{{MFunctor}}} from mmorph might be depending on the method using the associated type. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/16027> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #11042: Template Haskell / GHCi does not respect extra-lib-dirs
by GHC 11 Dec '18

11 Dec '18

#11042: Template Haskell / GHCi does not respect extra-lib-dirs -------------------------------------+------------------------------------- Reporter: mboes | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #10458 #5289 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In particular when compiling on NixOS, but also in many other situations, it is often needed to pass --extra-lib-dirs / --extra-include-dirs to cabal/stack, to help GHC find required system libraries. This works fine for GHC, but not GHCi, and therefore also not Template Haskell code. Minimal example attached. Try it in an environment where libz is not in a standard location, e.g. inside a nix-shell. Note that if you remove the template Haskell splice in Main.hs, the code compiles just fine. This affects GHC 7.10.2, but also HEAD from 2015-08-28, even one including Tamar Christina's 5d841108acef950fed6a5e608ac9b18e7431aa87 commit cherry- picked. I haven't been able to test more recent HEAD, because of unrelated compilation issues. I surmise that a fix to #10458, which currently blocks using HaskellR in GHCi, would also fix this, but I'm not sure. The error message I get is different: {{{ $ stack build --skip-ghc-check --extra-lib- dirs=/nix/store/31w31mc8immhpnmxvcl4l0fvc3i5iwh0-zlib-1.2.8/lib --extra- include- dirs=/nix/store/31w31mc8immhpnmxvcl4l0fvc3i5iwh0-zlib-1.2.8/include b-0.1.0.0: build Preprocessing executable 'b' for b-0.1.0.0... [2 of 2] Compiling Main ( src/Main.hs, .stack- work/dist/x86_64-linux/Cabal-1.23.0.0/build/b/b-tmp/Main.o ) <command line>: can't load .so/.DLL for: libz.so (libz.so: cannot open shared object file: No such file or directory) -- While building package b-0.1.0.0 using: /home/mboes/.stack/setup-exe-cache/setup-Simple- Cabal-1.23.0.0-x86_64-linux-ghc-7.11.20150828 --builddir=.stack- work/dist/x86_64-linux/Cabal-1.23.0.0/ build exe:b --ghc-options " -ddump- hi -ddump-to-file" Process exited with code: ExitFailure 1 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11042> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 38

[GHC] #15645: TypeChecking of Monad patterns incorrect with RebindableSyntax and OverloadedStrings
by GHC 11 Dec '18

11 Dec '18

#15645: TypeChecking of Monad patterns incorrect with RebindableSyntax and OverloadedStrings -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Using GHC 8.4.3, I'd expect the following to work: {{{#!hs {-# LANGUAGE RebindableSyntax, OverloadedStrings #-} module Fail where import Prelude hiding (fail) foo x = do Just y <- x return y newtype Text = Text String fail :: Text -> a fail (Text x) = error x fromString :: String -> Text fromString = Text }}} But it fails with: {{{ Fail.hs:8:5-15: error: * Couldn't match expected type `[Char]' with actual type `Text' * In a stmt of a 'do' block: Just y <- x In the expression: do Just y <- x return y In an equation for `foo': foo x = do Just y <- x return y | 8 | Just y <- x | ^^^^^^^^^^^ }}} Given the enabled extensions, I'd expect {{{foo}}} to desugar as: {{{#!hs foo x = x >>= \v -> case v of Just y -> return y _ -> fail (fromString "pattern match error") }}} But looking at TcMatches.tcMonadFailOp it checks the fail operation (which is literally {{{fail}}}) takes an argument of type tyString (e.g. {{{[Char]}}}). One way around that would be to make the "fail-op" being passed around be {{{fail . fromString}}} if the appropriate extensions are enabled. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15645> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 16