August 2013 - ghc-tickets

[GHC] #8133: T7881 fails with hpc
by GHC 03 Oct '13

03 Oct '13

#8133: T7881 fails with hpc ----------------------------------+-------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Code Coverage | Version: 7.7 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: Other Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+-------------------------- I noticed that T7881 fails with `hpc` way. I investigated a bit and I noticed that if I compile the program without hpc it emits 3 warnings (which is intended): {{{ [t-jastol@cam-05-unx : /5playpen/t-jastol/ghc- validate2/testsuite/tests/numeric/should_compile] '/5playpen/t-jastol/ghc- validate2/inplace/bin/ghc-stage2' -fforce-recomp -c T7881.hs -O T7881.hs:7:6: Warning: Enumeration is empty T7881.hs:25:6: Warning: Enumeration is empty T7881.hs:31:6: Warning: Enumeration is empty }}} But if I add `-fhpc` on the command line the warnings disappear: {{{ [t-jastol@cam-05-unx : /5playpen/t-jastol/ghc- validate2/testsuite/tests/numeric/should_compile] '/5playpen/t-jastol/ghc- validate2/inplace/bin/ghc-stage2' -fforce-recomp -c T7881.hs -O -fhpc [t-jastol@cam-05-unx : /5playpen/t-jastol/ghc- validate2/testsuite/tests/numeric/should_compile] }}} That's the reason why this test fails (mismatch of stderr). I don't know whether this is expected behaviour of hpc or not. If the former, then test configuration should be fixed, if the latter then hpc itself should be fixed. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8133> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #8129: Constraint solver panic when -ddump-tc-trace is used
by GHC 01 Oct '13

01 Oct '13

#8129: Constraint solver panic when -ddump-tc-trace is used -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.7 checker) | Operating System: Unknown/Multiple Keywords: | Type of failure: Compile-time Architecture: Unknown/Multiple | crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- {{{ {-# LANGUAGE MultiParamTypeClasses, TypeFamilies #-} {-# OPTIONS_GHC -ddump-tc-trace #-} type family F (x :: *) :: * class (y ~ F x) => C x y z = () :: C x y => () }}} causes a panic while tracing the typechecker: {{{ solveNestedImplications starting { original inerts = Equalities: Type-function equalities: [D] _ :: F x_aeH ~ y_aeI (CFunEqCan) Dictionaries: [W] $dC_aeK :: C x_aeH y_aeI (CDictCan) Irreds: Insolubles = {} Solved dicts 0 Solved funeqs 0 thinner_inerts = Equalities:ghc-stage2: panic! (the 'impossible' happened) (GHC version 7.7.20130812 for i386-unknown-linux): No match in record selector ctev_evar }}} If `-ddump-tc-trace` is not used, the correct constraint solving error is generated: {{{ Could not deduce (C x0 y0) arising from the ambiguity check for an expression type signature from the context (C x y) bound by an expression type signature: C x y => () }}} It seems that `prepareInertsForImplications` in `TcSMonad` assumes that all the `inert_funeqs` are givens or wanteds; if there are some deriveds, then the above panic results. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8129> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #8058: If .ghci is a symlink, permissions aren't read correctly
by GHC 24 Sep '13

24 Sep '13

#8058: If .ghci is a symlink, permissions aren't read correctly -------------------------------------------+------------------------------- Reporter: berdario | Owner: Type: bug | Status: new Priority: low | Milestone: Component: GHCi | Version: 7.6.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 hour) | Type of failure: Other Blocked By: | Test Case: Related Tickets: | Blocking: -------------------------------------------+------------------------------- dario@macbook ~> ls -l .ghci lrwxrwxrwx 1 dario dario 40 Jul 14 15:27 .ghci -> /home/dario/.dotfiles/dotfiles/ghci.conf dario@macbook ~> ls -l (readlink -f .ghci) -rw-r--r-- 1 dario dario 10 Jul 14 15:25 /home/dario/.dotfiles/dotfiles/ghci.conf dario@macbook ~> ghci GHCi, version 7.6.2: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. *** WARNING: /home/dario/.dotfiles/dotfiles is writable by someone else, IGNORING! Prelude> Obviously, /home/dario/.dotfiles/dotfiles isn't writable by someone else... Someone else could actually delete the symlink and maybe recreate it... but it couldn't inject malicious commands in the .ghci, unless the file pointed by the symlink was also writable by the attacker, in which case, checking the permissions of the target of the symlink would still prevent any wrongdoing -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8058> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #8192: Finally remove -fwarn-lazy-unlifted-bindings flag
by GHC 23 Sep '13

23 Sep '13

#8192: Finally remove -fwarn-lazy-unlifted-bindings flag ------------------------------------+------------------------------------- Reporter: thoughtpolice | Owner: thoughtpolice Type: bug | Status: new Priority: normal | Milestone: 7.10.1 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: #8022 | ------------------------------------+------------------------------------- See #8022. We should finally put this flag to rest. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8192> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #8202: ghc panic applyTypeToArgs
by GHC 19 Sep '13

19 Sep '13

#8202: ghc panic applyTypeToArgs -----------------------------------+--------------------------------------- Reporter: hth313 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time crash Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -----------------------------------+--------------------------------------- Building https://github.com/hth313/hthforth with ghc 7.6.2 on Linux or with 7.6.3 on ppc results in a ghc panic. (It works with ghc 7.2.2 on Mac OS X, I have not tested with any version between 7.2.2 and 7.6.2). Use cabal to build hthforth, vector-bytestring 0.0.0.2 is needed when using ghc 7.6 and it can be downloaded from https://github.com/basvandijk /vector-bytestring (it is currently not on Hackage). [..] [13 of 18] Compiling Language.Forth.Machine[boot] ( src/Language/Forth/Machine.hs-boot, dist/build/ppforth/ppforth- tmp/Language/Forth/Machine.o-boot ) [15 of 18] Compiling Language.Forth.Core[boot] ( src/Language/Forth/Core .hs-boot, dist/build/ppforth/ppforth-tmp/Language/Forth/Core.o-boot ) [17 of 18] Compiling Language.Forth.Core ( src/Language/Forth/Core.hs, dist/build/ppforth/ppforth-tmp/Language/Forth/Core.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.6.2 for x86_64-unknown-linux): applyTypeToArgs main:Language.Forth.Machine.$wlvl{v r1CC} [gid] @ cell{tv i589} [tv] ww_i9uI{v} [lid] ww_i9uJ{v} [lid] ww_i9uK{v} [lid] ww_i9uL{v} [lid] ww_i9uM{v} [lid] ww_i9uN{v} [lid] ww_i9uO{v} [lid] ww_i9uP{v} [lid] ww_i9uQ{v} [lid] ww_i9uR{v} [lid] transformers-0.3.0.0:Control.Monad.Trans.Reader.ReaderT{tc r1fq} (base:GHC.IORef.IORef{tc r1fp} haskeline-0.7.0.3:System.Console.Haskeline.History.History{tc r1fo}) (transformers-0.3.0.0:Control.Monad.Trans.Reader.ReaderT{tc r1fq} (base:GHC.IORef.IORef{tc r1fp} haskeline-0.7.0.3:System.Console.Haskeline.Command.KillRing.KillRing{tc r1fn}) (transformers-0.3.0.0:Control.Monad.Trans.Reader.ReaderT{tc r1fq} haskeline-0.7.0.3:System.Console.Haskeline.Prefs.Prefs{tc r1fO} (transformers-0.3.0.0:Control.Monad.Trans.Reader.ReaderT{tc r1fq} (haskeline-0.7.0.3:System.Console.Haskeline.InputT.Settings{tc r1fX} <nt>ghc-prim:GHC.Types.IO{tc 32I}) <nt>ghc-prim:GHC.Types.IO{tc 32I}))) (base:Data.Either.Either{tc 344} base:GHC.Base.String{tc 36u} (main:Language.Forth.Types.Lit{tc r10z} cell{tv i589} [tv]), main:Language.Forth.Machine.Machine{tc r1ev} cell{tv i589} [tv]) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8202> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #8185: Change role annotation syntax
by GHC 18 Sep '13

18 Sep '13

#8185: Change role annotation syntax ----------------------------------------------+---------------------------- Reporter: goldfire | Owner: Type: feature request | goldfire Priority: normal | Status: new Component: Compiler | Milestone: 7.8.1 Keywords: | Version: 7.7 Architecture: Unknown/Multiple | Operating System: Difficulty: Moderate (less than a day) | Unknown/Multiple Blocked By: | Type of failure: Related Tickets: | None/Unknown | Test Case: | Blocking: ----------------------------------------------+---------------------------- Currently, role annotations look like this: {{{ data Foo a@N = ... }}} I've received several criticisms of this syntax: * It is not backward compatible. If a library wishes to use role annotations and remain compilable with earlier versions of GHC, preprocessor commands are necessary. * It is inscrutable for someone not well-versed in roles. * It reminds people of as-patterns, which it is unrelated to. * It is conceivable that it would conflict with type-level as-patterns. For these reasons, I propose the following: {{{ data Foo a {-# ROLE Nominal #-} = ... }}} This syntax, while verbose, eliminates these concerns, considering that the new syntax is easily searchable for someone who doesn't know it. I have proposed something similar on ghc-devs, with no response, so I will implement it shortly. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8185> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15

[GHC] #8184: Compiler panic in the presence of cyclic imports
by GHC 15 Sep '13

15 Sep '13

#8184: Compiler panic in the presence of cyclic imports -----------------------------------+--------------------------------------- Reporter: parcs | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time crash Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: 910 Blocked By: | Related Tickets: | -----------------------------------+--------------------------------------- A.hs {{{ #!haskell module A where import {-# SOURCE #-} B data X = X Y }}} B.hs-boot {{{ #!haskell module B where data Y }}} B.hs {{{ #!haskell module B where import A data Y = Y Int Int thing :: X -> a thing (X (Y a b)) = thing (X (Y a b)) }}} C.hs {{{ #!haskell module C where import A import B panic :: Int -> a panic x = thing (X (Y x x)) }}} Now try to compile module C: {{{ $ ghc-stage2 -O C [1 of 4] Compiling B[boot] ( B.hs-boot, B.o-boot ) [2 of 4] Compiling A ( A.hs, A.o ) [3 of 4] Compiling B ( B.hs, B.o ) [4 of 4] Compiling C ( C.hs, C.o ) ghc-stage2: panic! (the 'impossible' happened) (GHC version 7.7.20130826 for x86_64-unknown-linux): applyTypeToArgs main:B.$wthing{v rsQ} [gid] @ a{tv ivX} [tv] ww_iwm{v} [lid] ww_iwn{v} [lid] a{tv ivX} [tv] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} I encountered this bug when attempting to compile GHC with GHC -O2 --make. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8184> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #8194: make install (at git ef01794) still fails
by GHC 15 Sep '13

15 Sep '13

#8194: make install (at git ef01794) still fails --------------------------------+------------------------------------------ Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Build System | Version: 7.7 Keywords: | Operating System: Linux Architecture: x86 | Type of failure: Installing GHC failed Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | --------------------------------+------------------------------------------ I think the last time `make install` worked for me was sometime in February or March 2013. The build succeeds but `make install` fails. mk/build.mk: {{{ BuildFlavour = perf V = 0 }}} Steps to reproduce: {{{ $ perl boot $ ./configure --prefix=/tmp/ghc/7.7.20130827 $ make $ make install [...] Installing library in /tmp/ghc/7.7.20130827/lib/ghc-7.7.20130827/haskell2010-1.1.1.0 "/tmp/ghc/7.7.20130827/lib/ghc-7.7.20130827/bin/ghc-pkg" --force --global-package-db "/tmp/ghc/7.7.20130827/lib/ghc-7.7.20130827/package.conf.d" update rts/dist/package.conf.install /tmp/ghc/7.7.20130827/lib/ghc-7.7.20130827/bin/ghc-pkg: error while loading shared libraries: libHSbin-package-db-0.0.0.0-ghc7.7.20130827.so: cannot open shared object file: No such file or directory make[1]: *** [install_packages] Error 127 make: *** [install] Error 2 }}} Related mailing list threads: * http://www.haskell.org/pipermail/ghc-devs/2013-August/002167.html * http://www.haskell.org/pipermail/ghc-devs/2013-April/000995.html * http://www.haskell.org/pipermail/ghc-devs/2013-March/000822.html -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8194> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #8051: GHCi: confusing `:set +m`/`:{` interaction & wrong line-numbers in multi-line input
by GHC 12 Sep '13

12 Sep '13

#8051: GHCi: confusing `:set +m`/`:{` interaction & wrong line-numbers in multi- line input ------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | 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: | ------------------------------------+------------------------------------- As mentioned in ticket:8047#comment:1 GHCi exhibits a line-numbering offset bug when multi-line input is evaluated. Morever, when `:set +m` is active, `:{`-entered multi-input may trigger multi-line input continuation, e.g.: {{{ Prelude> :set +m Prelude> :{ Prelude| let x = () Prelude| y = () Prelude| :} Prelude| z = () Prelude| Prelude> }}} The attached patch fixes both issues, but does so in an admittedly hacky way... -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8051> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #8196: Core Lint error in Specialise with PolyKinds and derived instance
by GHC 07 Sep '13

07 Sep '13

#8196: Core Lint error in Specialise with PolyKinds and derived instance -------------------------+------------------------------------------------- Reporter: | Owner: adamgundry | Status: new Type: bug | Milestone: Priority: | Version: 7.7 normal | Operating System: Unknown/Multiple Component: | Type of failure: Incorrect warning at Compiler | compile-time Keywords: | Test Case: Architecture: | Blocking: Unknown/Multiple | Difficulty: | Unknown | Blocked By: | Related Tickets: | -------------------------+------------------------------------------------- The following causes a lint error when compiled with `-O` (but not with `-O0`): {{{ {-# LANGUAGE PolyKinds #-} {-# OPTIONS_GHC -dcore-lint -O #-} data T a b = MkT (a b) deriving Show main = print (MkT (Just True)) }}} For reference, the beginning of the (rather long) error message is: {{{ *** Core Lint errors : in result of Specialise *** <no location info>: Warning: In the type ‛Main.T k_XlN Data.Maybe.Maybe GHC.Types.Bool’ Kind application error in type ‛Main.T k_XlN Data.Maybe.Maybe GHC.Types.Bool’ Function kind = forall (k_alL :: BOX). (k_alL -> *) -> k_alL -> * Arg kinds = [(k_XlN, BOX), (Data.Maybe.Maybe, * -> *), (GHC.Types.Bool, *)] }}} It looks like something is wrong with the types of the derived `Show` instance, when `PolyKinds` is enabled. A similar problem applies to `Eq` (and perhaps other classes). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8196> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6