February 2015 - ghc-tickets

[GHC] #9930: By default, a source code would get overwritten by executable on *nix
by GHC 31 May '15

31 May '15

#9930: By default, a source code would get overwritten by executable on *nix -------------------------------------+------------------------------------- Reporter: Rufflewind | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Other Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- If I have a source code without an extension, say `foo`, and I forget to specify the output file via `-o`, GHC will overwrite it with the executable itself after compilation. This occurs only on *nix-like operating systems. Presumably something similar could happen on Windows – fortunately, those who use `.exe` for source code are probably among the minority. Minimum example: {{{#!sh #!/bin/sh echo >foo 'main=undefined' ghc -x hs foo less foo # 'foo' now contains binary data }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9930> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #9584: Interface file errors (Iface type variable out of scope: k)
by GHC 27 May '15

27 May '15

#9584: Interface file errors (Iface type variable out of scope: k) -------------------------------------+------------------------------------- Reporter: jonsterling | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- (Please forgive me if I have not formatted this bug report properly) Anyway, yesterday in a project at work we started having a strange problem where pretty much any change in our code at all would result in the next build failing with this error: {{{ The interface for ‘main:HList’ Declaration for $fRLensk:r_$s$w$crlens: Iface type variable out of scope: k Cannot continue after interface file error }}} I can get around the problem by deleting the dist directory, but this is very unfortunate, since it basically changes my build/test cycle from a few seconds to a minutes because I can't take advantage of the cached builds of things that *haven't* changed. It seems like errors like this have cropped up a few times in GHC, but they've always been fixed so far, so hopefully someone here will be familiar with what is causing this one! Please let me know if there is further information I can provide. The file in question looks basically like this: (it depends on some other stuff in our project, and so it won't build immediately if you paste it onto your machine; let me know if you need me to bundle it up into something self-contained). {{{#!hs -- | A bespoke record/HList type. 'el' interprets fields into types; 'tot' is -- the maximal extension of the record type; and 'rs' is the subset of 'tot' -- contained in the record itself. data Record (el :: k -> *) (tot :: [k]) (rs :: [k]) where Nil :: Record el tot '[] (:*) :: ( ElemTF r tot ?? '("the key", r, "is not permitted in this record, which may only contain", tot) , DistinctTF (r ': rs) ?? '("the key", r, "is already in", rs) ) => el r -> Record el tot rs -> Record el tot (r ': rs) infixr 9 :* -- | Records have lenses for their fields. class ElemTF r rs ~ True => RLens rs r where rlens :: proxy r -> CL.Lens' (Record el tot rs) (el r) instance RLens (r ': rs) r where rlens _ = CL.lens (\(x :* _) -> x) (\(_ :* xs) x -> x :* xs) instance (ElemTF r (s ': rs) ~ True, RLens rs r) => RLens (s ': rs) r where rlens _ = CL.lens (\(_ :* xs) -> xs ^. rlens Proxy) (\(x :* xs) y -> x :* xs & rlens Proxy .~ y) -- | Records with fields in 'K' give rise to a functor from 'Hask^K' to 'Hask'. (<<$>>) :: (forall x. f x -> g x) -> Record f tot rs -> Record g tot rs _ <<$>> Nil = Nil eta <<$>> (x :* xs) = eta x :* (eta <<$>> xs) infixl 8 <<$>> -- | Records can be traversed to pull out some of their effects. rtraverse :: Applicative h => (forall x. f x -> h (g x)) -> Record f tot rs -> h (Record g tot rs) rtraverse _ Nil = pure Nil rtraverse f (x :* xs) = (:*) <$> f x <*> rtraverse f xs -- | As a special case, we can yank out the first layer of effects in a -- composed functor stack. rtraverse1 :: Applicative f => Record (f :. g) tot rs -> f (Record g tot rs) rtraverse1 = rtraverse getCompose -- | Records whose fields are uniform in type may be turned into a list. recordToList :: Record (Const t) tbl rs -> [t] recordToList Nil = [] recordToList (Const x :* xs) = x : recordToList xs instance Show (Record el tot '[]) where show _ = "Nil" instance ( Show (Record el tot rs) , Show (el r) ) => Show (Record el tot (r ': rs)) where show (x :* xs) = "(" ++ show x ++ " :* " ++ show xs ++ ")" data family Sing (a :: k) class SingI a where sing :: Sing a class kparam ~ Any => SingE (kparam :: k) rep | kparam -> rep where fromSing :: Sing (a :: k) -> rep }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9584> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #8122: make binary-dist broken on OS X in HEAD
by GHC 26 May '15

26 May '15

#8122: make binary-dist broken on OS X in HEAD --------------------------------+------------------------------------------ Reporter: danharaj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.7 Keywords: | Operating System: MacOS X Architecture: x86_64 | Type of failure: Installing GHC failed (amd64) | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | --------------------------------+------------------------------------------ After a successful configure and make, make binary-dist fails: {{{ ➜ ghc git:(master) make ===--- building phase 0 make -r --no-print-directory -f ghc.mk phase=0 phase_0_builds make[1]: Nothing to be done for `phase_0_builds'. ===--- building phase 1 make -r --no-print-directory -f ghc.mk phase=1 phase_1_builds make[1]: Nothing to be done for `phase_1_builds'. ===--- building final phase make -r --no-print-directory -f ghc.mk phase=final all make[1]: Nothing to be done for `all'. ➜ ghc git:(master) make binary-dist rm -f bindist-list make -r --no-print-directory -f ghc.mk bindist BINDIST=YES "cp" -p ghc/stage1/build/tmp/ inplace/lib/bin/ghc-stage1 cp: ghc/stage1/build/tmp/ is a directory (not copied). make[1]: *** [inplace/lib/bin/ghc-stage1] Error 1 make: *** [binary-dist-prep] Error 2 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8122> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #9950: Documentation for InterruptibleFFI contains broken example
by GHC 26 May '15

26 May '15

#9950: Documentation for InterruptibleFFI contains broken example -------------------------------------+------------------------------------- Reporter: hpd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.8.4 Documentation | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- In Section "8.1.4. Interruptible foreign calls" the example {{{#!hs foreign import ccall interruptible "sleep" :: CUint -> IO CUint }}} misses the haskell function name. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9950> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #10092: lex doesn't handle binary literals
by GHC 26 May '15

26 May '15

#10092: lex doesn't handle binary literals -------------------------------------+------------------------------------- Reporter: | Owner: RyanGlScott | Status: new Type: bug | Milestone: Priority: normal | Version: 7.10.1-rc2 Component: | Operating System: Unknown/Multiple libraries/base | Type of failure: Incorrect result Keywords: | at runtime Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The {{{lex}}} function from {{{Text.Read.Lex}}} (on which the {{{Read}}} instance for {{{Lexeme}}} is based) can't read binary literals on GHC 7.10.1-rc2: {{{ $ ghci -XBinaryLiterals GHCi, version 7.10.0.20150123: http://www.haskell.org/ghc/ :? for help λ> 0b101010 42 λ> import Text.Read.Lex λ> read "0b101010" :: Lexeme *** Exception: Prelude.read: no parse }}} This should be a simple fix, but I'm not sure if this is the intended behavior or not, since {{{BinaryLiterals}}} isn't a part of the Haskell 2010 standard (and I'm not sure how closely {{{lex}}} adheres to that). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10092> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #9899: HEAD: make clean fails to delete libraries/bootstrapping.conf (directory)
by GHC 25 May '15

25 May '15

#9899: HEAD: make clean fails to delete libraries/bootstrapping.conf (directory) -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Build System | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- {{{ "rm" -f libraries/bootstrapping.conf libraries/integer- gmp/cbits/GmpDerivedConstants.h libraries/integer- gmp/include/HsIntegerGmp.h libraries/integer-gmp2/include/HsIntegerGmp.h libraries/base/include/EventConfig.h mk/config.mk.old mk/project.mk.old compiler/ghc.cabal.old includes/GHCConstants.h includes/DerivedConstants.h includes/ghcautoconf.h includes/ghcplatform.h includes/ghcversion.h utils /ghc-pkg/Version.hs compiler/prelude/primops.txt rm: cannot remove `libraries/bootstrapping.conf': Is a directory make[1]: *** [clean_files] Error 1 }}} Then I do {{{ rm -r libraries/bootstrapping.conf make clean }}} and this succeeds. Now I build again: {{{ make }}} and get an error: {{{ "inplace/bin/ghc-cabal" configure libraries/binary dist-boot "" --with- ghc="/home/ggreif/bin/ghc" --with-ghc-pkg="/home/ggreif/bin/ghc-pkg" --package-db=/home/ggreif/%NoBackup%/ghc7/ghc-head- x86_64/libraries/bootstrapping.conf --disable-library-for-ghci --enable- library-vanilla --disable-library-profiling --disable-shared --configure- option=CFLAGS=" -fno-stack-protector " --configure-option=LDFLAGS=" " --configure-option=CPPFLAGS=" " --gcc-options=" -fno-stack-protector " --configure-option=--with-gmp-includes="/home/ggreif/include" --constraint "binary == 0.7.2.3" --constraint "Cabal == 1.21.1.0" --constraint "hpc == 0.6.0.2" --constraint "bin-package-db == 0.0.0.0" --constraint "hoopl == 3.10.0.2" --constraint "transformers == 0.4.2.0" --constraint "terminfo == 0.4.0.1" --with-gcc="/usr/bin/gcc" --configure- option=--with-cc="/usr/bin/gcc" --with-ar="/usr/bin/ar" --with- alex="/home/ggreif/bin/alex" --with-happy="/home/ggreif/bin/happy" Configuring binary-0.7.2.3... ghc-cabal: '/home/ggreif/bin/ghc-pkg' exited with an error: ghc-pkg: ghc no longer supports single-file style package databases (/home/ggreif/%NoBackup%/ghc7/ghc-head- x86_64/libraries/bootstrapping.conf) use 'ghc-pkg init' to create the database with the correct format. make[1]: *** [libraries/binary/dist-boot/package-data.mk] Error 1 }}} But the thing is created as a file now: {{{ $ ls -l libraries/bootstrapping.conf -rw-r--r-- 1 ggreif grp 3 Dec 18 11:17 libraries/bootstrapping.conf }}} I can recreate it manually: {{{ $ rm libraries/bootstrapping.conf $ /home/ggreif/bin/ghc-pkg init libraries/bootstrapping.conf $ ls -ld libraries/bootstrapping.conf drwxr-xr-x 2 ggreif grp 96 Dec 18 11:23 libraries/bootstrapping.conf }}} And now `make` works... -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9899> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #9841: Touching a file that uses TH triggers TH recompilation flood
by GHC 24 May '15

24 May '15

#9841: Touching a file that uses TH triggers TH recompilation flood -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Build System | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Building Blocked By: | GHC failed Related Tickets: #481, #7277 | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Check out this test case: https://github.com/nh2/ghc-th-recomp-touch-test I have 2 modules, A and B, both using TH (using aeson) with B importing A. After the first compilation, `touch A.hs && ghc --make B.hs` causes B to be recompiled. Why should this be the case? If we see that the A.hi file is completely identical with what it was before, why should we recompile B? This problem actually hits pretty hard when working in projects with > 200 modules. (This all is under the assumption that TH doesn't do any IO with observably different result; we do already have this assumption if I understand it correctly, since otherwise we would always recompile all TH code, which we don't.) ---- Another problem is that the process is not very repeatable: If you do `touch A.hs && ghc --make All.hs` and hit `Ctrl-C` before everything is done (e.g. after the 3rd modules), and then run just `ghc --make All.hs`, then GHC will decide to compile nothing at all, even though it had determined just before that everything needs to be recompiled. Is this expected? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9841> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #9709: Make restarts itself sometimes, and that's OK
by GHC 24 May '15

24 May '15

#9709: Make restarts itself sometimes, and that's OK -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- I fairly frequently get the message that `make` has restarted itself {{{ ghc.mk:100: *** Make has restarted itself 2 times; is there a makefile bug? See http://ghc.haskell.org/trac/ghc/wiki/Building/Troubleshooting#Makehasrestar… for details. Stop. }}} but then when I say `make` again, things proceed just fine. In particular, this always (I think) happens after I `make clean` in the `libraries` directory. If it matters, I always use the `-j` flag to `make`, sometimes with 2 cores and sometimes with 4. I'm on Mac OS 10.8. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9709> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #8549: GHCI incorrectly link symbols defined with foreign import ccall
by GHC 24 May '15

24 May '15

#8549: GHCI incorrectly link symbols defined with foreign import ccall -------------------------+------------------------------------------------- Reporter: | Owner: qnikst | Status: new Type: bug | Milestone: Priority: | Version: 7.6.3 normal | Operating System: Unknown/Multiple Component: GHCi | Type of failure: GHCi crash Keywords: | Test Case: Architecture: | https://gist.github.com/qnikst/324a66914b3aba878be5 Unknown/Multiple | Blocking: Difficulty: | Unknown | Blocked By: | Related Tickets: | -------------------------+------------------------------------------------- I have a problem that ghci when loads modules that uses external symbols incorrectly links them, the problem is not reproducible if I'm compiling executable or load modules with :load command. As a result every Pointer value is equivalent to constant 0x0000fffffff225ff. A minimal example is in attached link, it contains a small package and description how to reproduce a bug. Problem is also reproduces on the ghc-HEAD. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8549> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #9219: Parallel build proceeds despite errors
by GHC 23 May '15

23 May '15

#9219: Parallel build proceeds despite errors -------------------------+------------------------------------------------- Reporter: | Owner: jstolarek | Status: new Type: bug | Milestone: Priority: | Version: 7.8.2 normal | Operating System: Unknown/Multiple Component: | Type of failure: Incorrect warning at Driver | compile-time Keywords: | Test Case: Architecture: | Blocking: Unknown/Multiple | Difficulty: | Unknown | Blocked By: | Related Tickets: | -------------------------+------------------------------------------------- A few weeks back during my work on singletons I got the following build log: {{{ Building singletons-1.0... Preprocessing library singletons-1.0... [ 6 of 45] Compiling Data.Singletons.Util ( src/Data/Singletons/Util.hs, dist/build/Data/Singletons/Util.o ) [ 7 of 45] Compiling Data.Singletons.Syntax ( src/Data/Singletons/Syntax.hs, dist/build/Data/Singletons/Syntax.o ) [Data.Singletons.Util changed] [ 8 of 45] Compiling Data.Singletons.Names ( src/Data/Singletons/Names.hs, dist/build/Data/Singletons/Names.o ) [Data.Singletons.Util changed] [ 9 of 45] Compiling Data.Singletons.Promote.Monad ( src/Data/Singletons/Promote/Monad.hs, dist/build/Data/Singletons/Promote/Monad.o ) [Data.Singletons.Util changed] [10 of 45] Compiling Data.Singletons.Single.Monad ( src/Data/Singletons/Single/Monad.hs, dist/build/Data/Singletons/Single/Monad.o ) [Data.Singletons.Promote.Monad changed] [11 of 45] Compiling Data.Singletons.Promote.Eq ( src/Data/Singletons/Promote/Eq.hs, dist/build/Data/Singletons/Promote/Eq.o ) [Data.Singletons.Util changed] [12 of 45] Compiling Data.Singletons.Promote.Ord ( src/Data/Singletons/Promote/Ord.hs, dist/build/Data/Singletons/Promote/Ord.o ) [Data.Singletons.Util changed] [13 of 45] Compiling Data.Singletons.Promote.Bounded ( src/Data/Singletons/Promote/Bounded.hs, dist/build/Data/Singletons/Promote/Bounded.o ) [Data.Singletons.Util changed] [14 of 45] Compiling Data.Singletons.Promote.Type ( src/Data/Singletons/Promote/Type.hs, dist/build/Data/Singletons/Promote/Type.o ) [Data.Singletons.Util changed] [15 of 45] Compiling Data.Singletons.Promote.Defun ( src/Data/Singletons/Promote/Defun.hs, dist/build/Data/Singletons/Promote/Defun.o ) [Data.Singletons.Promote.Monad changed] [16 of 45] Compiling Data.Singletons.Promote ( src/Data/Singletons/Promote.hs, dist/build/Data/Singletons/Promote.o ) [Data.Singletons.Promote.Defun changed] [17 of 45] Compiling Data.Promotion.Prelude.Bounded ( src/Data/Promotion/Prelude/Bounded.hs, dist/build/Data/Promotion/Prelude/Bounded.o ) Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading package array-0.5.0.0 ... linking ... done. Loading package deepseq-1.3.0.2 ... linking ... done. Loading package containers-0.5.5.1 ... linking ... done. Loading package transformers-0.3.0.0 ... linking ... done. Loading package mtl-2.1.2 ... linking ... done. Loading package syb-0.4.1 ... linking ... done. Loading package pretty-1.1.1.1 ... linking ... done. Loading package template-haskell ... linking ... done. Loading package th-desugar-1.4.0 ... linking ... done. src/Data/Promotion/Prelude/Bounded.hs:34:27: Not in scope: ‘boundedTypes’ src/Data/Promotion/Prelude/Bounded.hs:34:27: GHC stage restriction: ‘boundedTypes’ is used in a top-level splice or annotation, and must be imported, not defined locally In the first argument of ‘promoteBoundedInstances’, namely ‘boundedTypes’ In the expression: promoteBoundedInstances boundedTypes [18 of 45] Compiling Data.Singletons.Single.Type ( src/Data/Singletons/Single/Type.hs, dist/build/Data/Singletons/Single/Type.o ) [Data.Singletons.Single.Monad changed] [19 of 45] Compiling Data.Singletons.Single.Eq ( src/Data/Singletons/Single/Eq.hs, dist/build/Data/Singletons/Single/Eq.o ) [Data.Singletons.Util changed] [20 of 45] Compiling Data.Singletons.Single.Data ( src/Data/Singletons/Single/Data.hs, dist/build/Data/Singletons/Single/Data.o ) [Data.Singletons.Single.Monad changed] [21 of 45] Compiling Data.Singletons.Single ( src/Data/Singletons/Single.hs, dist/build/Data/Singletons/Single.o ) [Data.Singletons.Promote changed] [22 of 45] Compiling Data.Singletons.Prelude.Instances ( src/Data/Singletons/Prelude/Instances.hs, dist/build/Data/Singletons/Prelude/Instances.o ) [Data.Singletons.Single changed] [23 of 45] Compiling Data.Singletons.Prelude.Bool ( src/Data/Singletons/Prelude/Bool.hs, dist/build/Data/Singletons/Prelude/Bool.o ) [Data.Singletons.Prelude.Instances changed] [24 of 45] Compiling Data.Singletons.Prelude.Eq ( src/Data/Singletons/Prelude/Eq.hs, dist/build/Data/Singletons/Prelude/Eq.o ) [Data.Singletons.Prelude.Bool changed] [25 of 45] Compiling Data.Singletons.CustomStar ( src/Data/Singletons/CustomStar.hs, dist/build/Data/Singletons/CustomStar.o ) [Data.Singletons.Prelude.Bool changed] [26 of 45] Compiling Data.Promotion.Prelude.Eq ( src/Data/Promotion/Prelude/Eq.hs, dist/build/Data/Promotion/Prelude/Eq.o ) [Data.Singletons.Prelude.Eq changed] [27 of 45] Compiling Data.Promotion.Prelude.Bool ( src/Data/Promotion/Prelude/Bool.hs, dist/build/Data/Promotion/Prelude/Bool.o ) [Data.Singletons.Prelude.Bool changed] [28 of 45] Compiling Data.Singletons.TypeRepStar ( src/Data/Singletons/TypeRepStar.hs, dist/build/Data/Singletons/TypeRepStar.o ) [Data.Singletons.Prelude.Eq changed] [29 of 45] Compiling Data.Singletons.Prelude.Ord ( src/Data/Singletons/Prelude/Ord.hs, dist/build/Data/Singletons/Prelude/Ord.o ) [Data.Singletons.Prelude.Bool changed] [30 of 45] Compiling Data.Promotion.Prelude.Ord ( src/Data/Promotion/Prelude/Ord.hs, dist/build/Data/Promotion/Prelude/Ord.o ) [Data.Singletons.Prelude.Ord changed] [31 of 45] Compiling Data.Singletons.TypeLits ( src/Data/Singletons/TypeLits.hs, dist/build/Data/Singletons/TypeLits.o ) [Data.Singletons.Prelude.Bool changed] [32 of 45] Compiling Data.Singletons.TH ( src/Data/Singletons/TH.hs, dist/build/Data/Singletons/TH.o ) [Data.Singletons.Prelude.Bool changed] [33 of 45] Compiling Data.Singletons.Prelude.Base ( src/Data/Singletons/Prelude/Base.hs, dist/build/Data/Singletons/Prelude/Base.o ) [Data.Singletons.Prelude.Bool changed] [34 of 45] Compiling Data.Singletons.Prelude.Either ( src/Data/Singletons/Prelude/Either.hs, dist/build/Data/Singletons/Prelude/Either.o ) [Data.Singletons.Prelude.Base changed] [35 of 45] Compiling Data.Promotion.Prelude.Either ( src/Data/Promotion/Prelude/Either.hs, dist/build/Data/Promotion/Prelude/Either.o ) [Data.Singletons.Prelude.Either changed] [36 of 45] Compiling Data.Singletons.Prelude.Tuple ( src/Data/Singletons/Prelude/Tuple.hs, dist/build/Data/Singletons/Prelude/Tuple.o ) [Data.Singletons.Prelude.Instances changed] [37 of 45] Compiling Data.Promotion.Prelude.Tuple ( src/Data/Promotion/Prelude/Tuple.hs, dist/build/Data/Promotion/Prelude/Tuple.o ) [Data.Singletons.Prelude.Tuple changed] [38 of 45] Compiling Data.Promotion.Prelude.Base ( src/Data/Promotion/Prelude/Base.hs, dist/build/Data/Promotion/Prelude/Base.o ) [Data.Singletons.Prelude.Base changed] [39 of 45] Compiling Data.Singletons.Prelude.List ( src/Data/Singletons/Prelude/List.hs, dist/build/Data/Singletons/Prelude/List.o ) [Data.Singletons.Prelude.Base changed] [40 of 45] Compiling Data.Singletons.Prelude.Maybe ( src/Data/Singletons/Prelude/Maybe.hs, dist/build/Data/Singletons/Prelude/Maybe.o )[Data.Singletons.Prelude.Instances changed] [41 of 45] Compiling Data.Singletons.Prelude ( src/Data/Singletons/Prelude.hs, dist/build/Data/Singletons/Prelude.o ) [Data.Singletons.Prelude.Base changed] [42 of 45] Compiling Data.Promotion.Prelude.List ( src/Data/Promotion/Prelude/List.hs, dist/build/Data/Promotion/Prelude/List.o ) [Data.Promotion.Prelude.Ord changed] [43 of 45] Compiling Data.Promotion.Prelude.Maybe ( src/Data/Promotion/Prelude/Maybe.hs, dist/build/Data/Promotion/Prelude/Maybe.o ) [Data.Singletons.Prelude.Maybe changed] [45 of 45] Compiling Data.Promotion.TH ( src/Data/Promotion/TH.hs, dist/build/Data/Promotion/TH.o ) [Data.Singletons.Prelude.Bool changed] }}} Notice how file 18 of 45 fails to build and yet the build does not stop. It seems that while one thread fails the remaining ones pick up other files that can be compiled despite the failure. I'm not really sure if I'm against this design choice, but I'd certainly expect to get information that something went wrong during the build. Here I was confused when I realised that despite seemingly successful compilation my package was not built. Only after examining the build log I saw that one of the modules failed to build. This should be changed to clearly notify the user that compilation was not successful. PS. At first I thought this is cabal-install's fault, but [https://github.com/haskell/cabal/issues/1809 this was ruled out]. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9219> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1