November 2015 - ghc-tickets

[GHC] #9613: when giving an error "No instance for C (a -> b)", suggest that a function may be underapplied
by GHC 15 Dec '15

15 Dec '15

#9613: when giving an error "No instance for C (a -> b)", suggest that a function may be underapplied -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.3 checker) | Operating System: Keywords: | Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Difficulty: Unknown | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Suggestion of ibotty here: http://www.reddit.com/r/haskell/comments/2go92u/beginner_error_messages_in_… {{{ Prelude> print length <interactive>:2:1: No instance for (Show ([a0] -> Int)) arising from a use of ‘print’ but there is an instance for (Show Int); maybe you omitted an argument to ‘length’ of type [a0]? In the expression: print length In an equation for ‘it’: it = print length }}} I guess the trickiest part will be figuring out what function is underapplied. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9613> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #9677: "operation not permitted" when running tests on Windows
by GHC 15 Dec '15

15 Dec '15

#9677: "operation not permitted" when running tests on Windows -------------------------------------+------------------------------------- Reporter: gintas | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: Difficulty: Unknown | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- When I run ghc tests on windows using "make test", I see instances of the following: =====> T5442d(normal) 86 of 4093 [0, 1, 0] cd ./cabal && $MAKE -s --no-print-directory T5442d </dev/null >T5442d.run.stdout 2>T5442d.run.stderr [Errno 1] Operation not permitted: './cabal/package.conf.T5442d.global' [Errno 90] Directory not empty: './cabal/package.conf.T5442d.global' [Errno 1] Operation not permitted: './cabal/package.conf.T5442d.user' [Errno 90] Directory not empty: './cabal/package.conf.T5442d.user' [Errno 1] Operation not permitted: './cabal/package.conf.T5442d.extra' Not sure if these are legitimately harmful, but something is going wrong. I am running ghc head on latest msys2. I also tried running the process as administrator to rule out permission issues due to handling symlinks. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9677> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #9687: Missing Typeable instances for built-in types
by GHC 15 Dec '15

15 Dec '15

#9687: Missing Typeable instances for built-in types -------------------------------------+------------------------------------- Reporter: selinger | 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: -------------------------------------+------------------------------------- According to the PolyTypeable wiki, https://ghc.haskell.org/trac/ghc/wiki/GhcKinds/PolyTypeable, "Users can no longer giving manual instances of `Typeable`; they must be derived." I cannot figure out how to do this for built-in types with missing `Typeable` instances. For example, my code requires a `Typeable` instance for 8-tuples. However, `Typeable` instances are natively only defined for 2- to 7-tuples: {{{ Prelude> :m Data.Typeable Prelude Data.Typeable> typeOf (1) Integer Prelude Data.Typeable> typeOf (1,2) (Integer,Integer) Prelude Data.Typeable> typeOf (1,2,3) (Integer,Integer,Integer) Prelude Data.Typeable> typeOf (1,2,3,4) (Integer,Integer,Integer,Integer) Prelude Data.Typeable> typeOf (1,2,3,4,5) (Integer,Integer,Integer,Integer,Integer) Prelude Data.Typeable> typeOf (1,2,3,4,5,6) (Integer,Integer,Integer,Integer,Integer,Integer) Prelude Data.Typeable> typeOf (1,2,3,4,5,6,7) (Integer,Integer,Integer,Integer,Integer,Integer,Integer) Prelude Data.Typeable> typeOf (1,2,3,4,5,6,7,8) <interactive>:10:1: No instance for (Typeable (,,,,,,,)) arising from a use of ‘typeOf’ In the expression: typeOf (1, 2, 3, 4, 5, 6, 7, 8) In an equation for ‘it’: it = typeOf (1, 2, 3, 4, 5, 6, 7, 8) Prelude Data.Typeable> }}} Since my code does not define the type of 8-tuples (it is defined in the Prelude, or even in the compiler), it is not possible to "derive" a Typeable instance for it. With the old Typeable class, I could just define it myself: {{{ instance (Typeable a, Typeable b, Typeable c, Typeable d, Typeable e, Typeable f, Typeable g, Typeable h) => Typeable (a,b,c,d,e,f,g,h) where typeOf _ = typerep where typerep = mkTyCon3 "GHC" "Tuple" "(,,,,,,,)" `mkTyConApp` [ typeOf (undefined :: a), typeOf (undefined :: b), typeOf (undefined :: c), typeOf (undefined :: d), typeOf (undefined :: e), typeOf (undefined :: f), typeOf (undefined :: g), typeOf (undefined :: h) ] }}} With the new `Typeable` class, I am completely stumped. How can I "derive" an instance for a pre-defined type? I think this is a bug. `Typeable` instances should be pre-defined for all pre-defined types, including //n//-tuples for all //n//. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9687> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #9983: configure script invokes ghc with LDFLAGS during cross-builds
by GHC 15 Dec '15

15 Dec '15

#9983: configure script invokes ghc with LDFLAGS during cross-builds -------------------------------------+------------------------------------- Reporter: newsham | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build | Version: 7.8.4 System | Operating System: Unknown/Multiple Keywords: | Type of failure: Building GHC Architecture: | failed Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- When building ghc, the aclocal.m4 settings direct "configure" to use the provided LDFLAGS as GHC_LDFLAGS, which are later used to invoke the host's GHC: https://github.com/ghc/ghc/blob/ghc-7.8/aclocal.m4#L1820 This is undesirable when performing a cross-build, in which case the LDFLAGS are used to specify the flags for use when linking for the target and not when linking on the build host. rwbarton@freenode believes that the normal CFLAGS, LDFLAGS, LIBS, etc. should never have an affect on the build host behavior. Either this policy needs to be enforced or a separate set of flags needs to be introduced to allow setting the target flags separately from the build host flags. To reproduce, "./configure LDFLAGS=bogus" and observe the failure in ghc- pwd, which is used on the build host. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9983> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #9731: Inductive type definitions on Nat
by GHC 15 Dec '15

15 Dec '15

#9731: Inductive type definitions on Nat -------------------------------------+------------------------------------- Reporter: barney | Owner: Type: feature request | 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: -------------------------------------+------------------------------------- If you define your own type-level natural numbers by promoting {{{#!hs data Nat = Zero | Successor Nat }}} you can then define both data and type families inductively, for example {{{#!hs data family Vector1 :: Nat -> * -> * data instance Vector1 Zero a = EmptyVector data instance Vector1 (Successor n) a = MkVector a (Vector1 n a) }}} Using the built-in Nat, there is no way to define inductive data families, and inductive type families such as {{{#!hs type family Vector2 :: Nat -> * -> * where Vector2 0 a = () Vector2 n a = (a, (Vector2 (n-1) a)) }}} require UndecidableInstances (and must be closed). This proposal is to add (n+k) patterns for Nat, so that the built-in naturals can be used in the same way that the user defined naturals can, to define type and data families inductively. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9731> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #9735: Template Haskell for cross compilers (port from GHCJS)
by GHC 15 Dec '15

15 Dec '15

#9735: Template Haskell for cross compilers (port from GHCJS) -------------------------------------+------------------------------------- Reporter: luite | Owner: Type: task | Status: new Priority: normal | Milestone: 7.10.1 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: -------------------------------------+------------------------------------- GHCJS supports Template Haskell by running it outside the compiler's process, with a different implementation of the Quasi type class. This can be done for other cross compilers too, if GHC gets an option to serialize Template Haskell requests and pass them to an external process. Someone started the work on this, but I think he stopped. I still have a document with a step by step plan to build an iOS cross compiler, with pointers to the relevant GHC and GHCJS code. https://github.com/ghcjs/ghcjs/wiki/Porting-GHCJS-Template-Haskell-to-GHC -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9735> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #9784: Allow Qualified Promoted Types
by GHC 15 Dec '15

15 Dec '15

#9784: Allow Qualified Promoted Types -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Parser) | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: GHC Blocked By: | rejects valid program Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- The program {{{#!hs {-# LANGUAGE DataKinds #-} module Foo where import Data.Proxy data MyNat = Z | S MyNat bar :: Proxy Foo.'Z -> Int bar _ = 0 }}} fails with the error {{{ Foo.hs:7:17: Illegal symbol '.' in type Perhaps you intended to use RankNTypes or a similar language extension to enable explicit-forall syntax: forall <tvs>. <type> Failed, modules loaded: none. }}} I believe the program above should compile without error. In the example above, I could make the code compile with my intended meanign using `Z`, `'Z`, or even `Foo.Z` in place of `Foo.'Z`, all of which refer to `Foo.'Z`. However, if there is also a vanilla type `Z` in scope and another promoted constructor `'Z` in scope, I have no way to disambiguate the reference to `'Z` in `bar`: - `Z` and `Foo.Z` refer to the vanilla type - `'Z` could be from the promoted `MyNat` constructor, or from the other module Concretely, I could import `Data.Type.Natural` from [https://hackage.haskell.org/package/type-natural type-natural], which also defines the promoted constructor `'Z`. {{{#!hs {-# LANGUAGE DataKinds #-} module Foo where import Data.Proxy import Data.Type.Natural data MyNat = Z | S MyNat bar :: Proxy Foo.'Z -> Int bar _ = 0 }}} In this case, there is no way for me to indicate that `bar` has the type `Foo.'Z -> Int` As a side note, if I do as the error suggests and use`RankNTypes`, I get the same error message. It's a bit strange for GHC suggest adding an extension that is already enabled. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9784> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #9820: Apparently inconsistent behaviour in the presence of OverlappingInstances
by GHC 15 Dec '15

15 Dec '15

#9820: Apparently inconsistent behaviour in the presence of OverlappingInstances -------------------------------------+------------------------------------- Reporter: kosmikus | 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: -------------------------------------+------------------------------------- This report is inspired by http://stackoverflow.com/questions/27051640 /strange-behavior-when-adding-constraint-to-instance I'm not sure if it is a bug, but it certainly feels strange and inconsistent to me, so I'd like to get some clarification. Here's a self-contained example of the behaviour: {{{#!hs {-# LANGUAGE FlexibleInstances, OverlappingInstances #-} module Overlap where class C a where foo :: a -> a instance C a where foo = id instance C Int where foo = (+1) -- Note that this one does not mention class C anywhere: class D a where bar :: a -> a instance D a where bar = foo -- this works and picks the 'C a' instance always -- The following does not compile without IncoherentInstances: {- baz :: a -> a baz = foo -} }}} I'm surprised that the definitions of `bar` and `baz` are treated differently. Shouldn't they either both require `IncoherentInstances`, or both work? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9820> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #9846: GHC --make should also look for .hi, not only for .hs
by GHC 15 Dec '15

15 Dec '15

#9846: GHC --make should also look for .hi, not only for .hs -------------------------------------+------------------------------------- Reporter: larsrh | Owner: Type: feature request | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Currently, `ghc --make` will only consider .hs source files from the include path. Example (assuming `Library` can't be resolved from the package database): `A.hs` {{{#!hs module A where import B import Library }}} `B.hs` {{{#!hs module B where }}} Compiling these files with `ghc --make -Idir A.hs B.hs` will succeed only if GHC finds a `Library.hs` file. In a thread on [https://www.haskell.org/pipermail/glasgow-haskell- users/2014-November/025476.html glasgow-haskell-users], Simon proposed relaxing this constraint; namely: In `--make` mode, when encountering an import `X`, GHC will try the following in order: 1. resolve the import from a package 2. search the include path for `X.hs` or `X.lhs` 3. search the include path for `X.hi` It already does 1 and 2, and this proposal would add 3. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9846> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #9862: defined but not used errors on Solaris/SPARC
by GHC 15 Dec '15

15 Dec '15

#9862: defined but not used errors on Solaris/SPARC -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (NCG) | Version: 7.8.2 Keywords: | Operating System: Solaris Architecture: sparc | Type of failure: Incorrect Difficulty: Unknown | warning at compile-time Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- I recently tried building GHC on Solaris and I got a ton of these files when compiling the bootstrapping copy of Cabal: {{{ "/afs/sipb/user/ezyang/ghc-7.8.2/usr/bin//ghc" -H32m -O -Werror -Wall -H64m -O0 \ -optc-Werror -optc-Wall -optc-fno-stack-protector \ \ --make utils/ghc-cabal/Main.hs -o utils/ghc- cabal/dist/build/tmp/ghc-cabal \ -no-user-package-db \ -Wall -fno-warn-unused-imports -fno-warn-warnings- deprecations \ -DCABAL_VERSION=1,21,1,0 \ -DBOOTSTRAPPING \ -odir bootstrapping \ -hidir bootstrapping \ -ilibraries/Cabal/Cabal \ -ilibraries/binary/src -DGENERICS \ -ilibraries/filepath \ -ilibraries/hpc \ -w "rm" -f compiler/stage1/build/Config.hs Creating compiler/stage1/build/Config.hs ... "rm" -f utils/ghc-pkg/dist/build/Version.hs echo "module Version where" >> utils/ghc- pkg/dist/build/Version.hs echo "version, targetOS, targetARCH :: String" >> utils/ghc- pkg/dist/build/Version.hs echo "version = \"7.9.20141204\"" >> utils/ghc- pkg/dist/build/Version.hs echo "targetOS = \"solaris2\"" >> utils/ghc- pkg/dist/build/Version.hs echo "targetARCH = \"sparc\"" >> utils/ghc-pkg/dist/build/Version.hs done. [ 1 of 86] Compiling Distribution.Compat.CreatePipe ( libraries/Cabal/Cabal/Distribution/Compat/CreatePipe.hs, bootstrapping/Distribution/Compat/CreatePipe.o ) cc1: warnings being treated as errors /tmp/ghc322370_0/ghc322370_21.hc: In function ‘s1xM_entry’: /tmp/ghc322370_0/ghc322370_21.hc:21:0: error: label ‘_c312’ defined but not used /tmp/ghc322370_0/ghc322370_21.hc: In function ‘s1xK_entry’: /tmp/ghc322370_0/ghc322370_21.hc:63:0: error: label ‘_c31b’ defined but not used }}} Maybe the 7.8.2 codegen which I bootstrapped from is buggy in some way? It makes it mildly difficult to actually validate. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9862> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1