March 2015 - ghc-tickets

[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 23 May '15

23 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

[GHC] #8555: Simplify given `Coercible` constraints
by GHC 19 May '15

19 May '15

#8555: Simplify given `Coercible` constraints -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.7 checker) | Operating System: Unknown/Multiple Keywords: | Type of failure: GHC rejects Architecture: Unknown/Multiple | valid program Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8503 | -------------------------------------+------------------------------------- It would be feasible and possibly useful if {{{ foo :: Coercible [a] [b] => a -> b foo = coerce }}} would work. This involve simplifying `CtGiven`s similar to how given (nominal) equalities are simplified. I’ll defer working on this, as it is not strictly required, it seems. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8555> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #8799: Orientation of given `Coercible` constraints
by GHC 19 May '15

19 May '15

#8799: Orientation of given `Coercible` constraints -------------------------------------------+------------------------------- Reporter: nomeata | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.6.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: #8555 | Test Case: | Blocking: -------------------------------------------+------------------------------- {{{ Prelude> :m + GHC.Exts Prelude GHC.Exts> let f :: Coercible a b => b -> a ; f = coerce <interactive>:3:40: Could not coerce from ‛b’ to ‛a’ because ‛b’ and ‛a’ are different types. arising from a use of ‛coerce’ from the context (Coercible a b) bound by the type signature for f :: Coercible a b => b -> a at <interactive>:3:10-32 In the expression: coerce In an equation for ‛f’: f = coerce }}} Something better could be done here (but its not clear what exactly, and to what general extend). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8799> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #10110: Compiling unit fails with Loading temp shared object failed
by GHC 19 May '15

19 May '15

#10110: Compiling unit fails with Loading temp shared object failed -------------------------------------+------------------------------------- Reporter: trommler | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: GHCi | Version: 7.10.1-rc2 Keywords: | Operating System: Linux Architecture: | Type of failure: Compile-time Unknown/Multiple | crash Test Case: | Blocked By: Blocking: | Related Tickets: #10058 Differential Revisions: | -------------------------------------+------------------------------------- @goldfire reported in #10058 in comment 1 another failure: {{{ [43 of 55] Compiling Tests.Compile.UnitParser ( Tests/Compile/UnitParser.hs, dist/build/main/main- tmp/Tests/Compile/UnitParser.o ) <no location info>: ghc: panic! (the 'impossible' happened) (GHC version 7.10.0.20150123 for x86_64-unknown-linux): Loading temp shared object failed: /tmp/ghc6444_0/libghc6444_264.so: undefined symbol: DataziMetrologyziSIziUnits_zdfShowHectare_closure Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} While on the surface this looks like a duplicate of #10058 it is not. The issue is only on Linux (travis to be precise), not OSX. Looking at the undefined symbol, here we see a symbol from the current module whereas in #10058 the undefined symbol lives in one of the packages. My theory is that the travis machine is running a modified link editor that defaults to `--as-needed` being set whereas the binutils default is `-no-as-needed`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10110> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 16

[GHC] #8789: includes/stg/SMP.h: use 'NOSMP' instead of never defined 'WITHSMP'
by GHC 13 May '15

13 May '15

#8789: includes/stg/SMP.h: use 'NOSMP' instead of never defined 'WITHSMP' ------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Looks like WITHSMP is not generated anywere, thus don't know how it worked before. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8789> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #10177: Typeable solver regression
by GHC 13 May '15

13 May '15

#10177: Typeable solver regression -------------------------------------+------------------------------------- Reporter: glguy | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.10.1 Component: Compiler | Version: 7.10.1-rc3 (Type checker) | Operating System: Unknown/Multiple Keywords: | Type of failure: GHC rejects Architecture: | valid program Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- This bug is known and fixed in master. Simon and Austin and Iavor are all aware of it. This ticket exists to ensure that the fix doesn't get lost. This code breaks under the Typeable solver in 7.10.1-rc3 and is fixed in master. The relevant commit in master is 3a0019e3672097761e7ce09c811018f774febfd2 : Improve `Typeable` solver. {{{ {-# LANGUAGE PolyKinds #-} {-# LANGUAGE FlexibleContexts #-} module Bug where import Data.Typeable newtype V n a = V [a] class Typeable a => C a instance (Typeable (V n), Typeable a) => C (V n a) -- Bug.hs:13:10: -- Could not deduce (Typeable (V n a)) -- arising from the superclasses of an instance declaration -- from the context (Typeable (V n), Typeable a) -- bound by the instance declaration at Bug.hs:13:10-50 -- In the instance declaration for ‘C (V n a)’ }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10177> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #10206: Incorrect links are generated for modules in the index of "Haskell Hiearchical Libraries"
by GHC 11 May '15

11 May '15

#10206: Incorrect links are generated for modules in the index of "Haskell Hiearchical Libraries" -------------------------------------+------------------------------------- Reporter: pgj | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.10.2 Component: | Version: 7.10.1-rc1 Documentation | Operating System: Unknown/Multiple Keywords: | Type of failure: Documentation Architecture: | bug Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- This was originally spotted and [https://mail.haskell.org/pipermail/ghc- devs/2015-February/008407.html posted to the ghc-devs mailing list] by Joachmin Breitner, but apparently since nobody has submitted a ticket for this relatively serious issue, here it is. I am quoting Joachim: {{{ while the index at http://haskell.inf.elte.hu/docs/7.11.20150222.noWin32/html/libraries/index.… exists, navigating to http://haskell.inf.elte.hu/docs/7.11.20150222.noWin32/html/libraries/Data- Char.html yields a 404 error. Same for http://haskell.inf.elte.hu/docs/latest/html/libraries/Data-Char.html }}} And [https://mail.haskell.org/pipermail/ghc-devs/2015-February/008408.html I have replied] the following to his initial email (I am involved in this because I am doing daily snapshots of the documentation through my FreeBSD GHC builders): {{{ Yes, I can confirm this bug. For what it is worth, the files are all there, the link appears to be broken: it is missing the subdirectory with the name of the package. That is, the proper link should be something like that: http://haskell.inf.elte.hu/docs/7.9.20141222.noWin32/html/libraries/base-4.… /Data-Char.html (Note the missing "base-4.8.0.0".) I have checked this with GHC 7.8.3, and everything is right there, while this problem seems to appear with GHC 7.10 RC2 and GHC-HEAD (starting from somewhere between mid-September and November -- that is what a quick bisecting tells me). }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10206> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #10210: Documentation link to 7.10.1 migration guide broken
by GHC 11 May '15

11 May '15

#10210: Documentation link to 7.10.1 migration guide broken -------------------------------------+------------------------------------- Reporter: | Owner: thoughtpolice thoughtpolice | Status: new Type: bug | Milestone: 7.10.2 Priority: normal | Version: 7.10.1 Component: | Operating System: Unknown/Multiple Documentation | Type of failure: None/Unknown Keywords: | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- When publishing the users guide to https://downloads.haskell.org/~ghc/7.10.1/docs/html/users_guide/release-7-1…, several users reported the 'Migration Guide' hyperlinks were broken. Turns out they were; the HTML looked something like this: {{{ </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p> GHC has implemented "The Applicative Monad Proposal", meaning the <code class="literal">Applicative</code> typeclass is now a superclass of <code class="literal">Monad</code>. This is a breaking change and your programs will need to be updated. Please see the <a class="ulink" href="" target="_top">GHC 7.10 Migration Guide</a> on the GHC wiki. }}} with an empty `href`. This ticket is so we don't lose track of this bug for 7.10.2. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10210> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3