May 2017 - ghc-tickets

[GHC] #11672: Poor error message
by GHC 27 Jul '17

27 Jul '17

#11672: Poor error message -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: adamgundry Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc2 (Type checker) | Keywords: ErrorMessages | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: #11198 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- [https://mail.haskell.org/pipermail/haskell-cafe/2016-February/123262.html Daniel Díaz recently pointed out] a particularly terrible error message. Here's a reduced example: {{{#!hs {-# LANGUAGE DataKinds #-} {-# LANGUAGE KindSignatures #-} module BadError where import GHC.TypeLits import Data.Proxy f :: Proxy (a :: Symbol) -> Int f _ = f (Proxy :: Proxy (Int -> Bool)) }}} With GHC 8.0 RC2, this leads to the following error: {{{ • Expected kind ‘Proxy ((->) Int Bool)’, but ‘Data.Proxy.Proxy :: Proxy (Int -> Bool)’ has kind ‘Proxy (Int -> Bool)’ • In the first argument of ‘f’, namely ‘(Proxy :: Proxy (Int -> Bool))’ In the expression: f (Proxy :: Proxy (Int -> Bool)) In an equation for ‘f’: f _ = f (Proxy :: Proxy (Int -> Bool)) }}} or with `-fprint-explicit-kinds -fprint-explicit-coercions`: {{{ • Expected kind ‘Proxy Symbol (((->) |> <*>_N -> <*>_N -> U(hole:{aCy}, *, Symbol)_N) Int Bool)’, but ‘(Data.Proxy.Proxy) @ k_aCv @ t_aCw :: Proxy (Int -> Bool)’ has kind ‘Proxy * (Int -> Bool)’ }}} As Iavor, Richard and I discussed, this message has at least three separate problems: * It says `kind` when it should say `type`. * `((->) Int Bool)` is printed instead of `Int -> Bool` (because there is a coercion hiding in the type). * The real error is the insoluble constraint `Symbol ~ *`, which is not reported at all! The first two should be fairly easy to fix. For the third, when reporting insoluble constraints, we should prefer to report those on which no other constraints depend. (In this case, the presence of `hole:{aCy}` in the constraint is an explicit dependency on the other constraint.) I'll try to take a look at this. It is no doubt related to #11198. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11672> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #13530: Horrible error message due to TypeInType
by GHC 27 Jul '17

27 Jul '17

#13530: Horrible error message due to TypeInType -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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: -------------------------------------+------------------------------------- Consider this {{{ {-# LANGUAGE MagicHash, UnboxedTuples #-} module Foo where import GHC.Exts g :: Int -> (# Int#, a #) g (I# y) = (# y, undefined #) f :: Int -> (# Int#, Int# #) f x = g x }}} With GHC 8 we get {{{ Foo.hs:11:7: error: • Couldn't match a lifted type with an unlifted type Expected type: (# Int#, Int# #) Actual type: (# Int#, Int# #) }}} What a terrible error message!! It was much better in GHC 7.10: {{{ Foo.hs:11:7: Couldn't match kind ‘*’ with ‘#’ When matching types a0 :: * Int# :: # Expected type: (# Int#, Int# #) Actual type: (# Int#, a0 #) }}} What's going on? The constraint solver sees {{{ [W] alpha::TYPE LiftedRep ~ Int#::TYPE IntRep }}} So it homogenises the kinds, ''and unifies alpha'' (this did not happen in GHC 7.10), thus {{{ alpha := Int# |> TYPE co [W] co :: LiftedRep ~ IntRep }}} Of course the new constraint fails. But since we have unified alpha, when we print out the types are are unifying they both look like `(# Int#, Int# #)` (there's a suppressed cast in the second component). I'm not sure what to do here. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13530> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #12373: Type error but types match
by GHC 27 Jul '17

27 Jul '17

#12373: Type error but types match -------------------------------------+------------------------------------- Reporter: osa1 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 (Type checker) | 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: -------------------------------------+------------------------------------- {{{ > unboxedsums git:(prim_sums_rebase_5) x cat primop_bug.hs {-# LANGUAGE MagicHash, ScopedTypeVariables, UnboxedTuples #-} module Main where import GHC.MVar import GHC.Prim import GHC.Types main :: IO () main = IO (\rw -> newMVar# rw) >> return () > unboxedsums git:(prim_sums_rebase_5) x ghc-stage1 primop_bug.hs -ddump- stg -ddump-cmm -ddump-to-file -fforce-recomp -dumpdir primop_fails -O -fprint-explicit-kinds [1 of 1] Compiling Main ( primop_bug.hs, primop_bug.o ) primop_bug.hs:10:19: error: • Couldn't match a lifted type with an unlifted type Expected type: (# State# RealWorld, MVar# RealWorld a0 #) Actual type: (# State# RealWorld, MVar# RealWorld a0 #) • In the expression: newMVar# rw In the first argument of ‘IO’, namely ‘(\ rw -> newMVar# rw)’ In the first argument of ‘(>>)’, namely ‘IO (\ rw -> newMVar# rw)’ }}} Tried with HEAD, 8.0.1. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12373> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #12801: Misleading error message when deriving Functor
by GHC 25 Jul '17

25 Jul '17

#12801: Misleading error message when deriving Functor -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Poor/confusing Unknown/Multiple | error message Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Compiling this trivial demo program: {{{ data Container = Container [Wibble Int] deriving (Eq, Show) data Wibble a = Wibble a | Wobble deriving (Eq, Functor, Show) }}} results in the error message: {{{ a.hs:6:13: error: • No instance for (Eq (Wibble Int)) arising from the first field of ‘Container’ (type ‘[Wibble Int]’) Possible fix: use a standalone 'deriving instance' declaration, so you can specify the instance context yourself • When deriving the instance for (Eq Container) a.hs:6:17: error: • No instance for (Show (Wibble Int)) arising from the first field of ‘Container’ (type ‘[Wibble Int]’) Possible fix: use a standalone 'deriving instance' declaration, so you can specify the instance context yourself • When deriving the instance for (Show Container) a.hs:12:17: error: • Can't make a derived instance of ‘Functor Wibble’: You need DeriveFunctor to derive an instance for this class • In the data declaration for ‘Wibble’ }}} The "No instance for (Eq|Show)" are rather misleading, because the *actual* error is that the `{-# LANGUAGE DeriveFunctor #-}` pragma is missing. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12801> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #10684: Error cascade when unrelated class derivation fails
by GHC 25 Jul '17

25 Jul '17

#10684: Error cascade when unrelated class derivation fails -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.11 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Pretty minor bug, but I thought I'd point it out: {{{ module A where import Data.Typeable data A = A deriving (Show, Typeable) data B = B A deriving (Show) }}} I get two errors when I expect one: {{{ A.hs:3:28: Can't make a derived instance of `Typeable A': You need -XDeriveDataTypeable to derive an instance for this class In the data declaration for `A' A.hs:4:24: No instance for (Show A) arising from the 'deriving' clause of a data type declaration Possible fix: add an instance declaration for (Show A) or use a standalone 'deriving instance' declaration, so you can specify the instance context yourself When deriving the instance for (Show B) }}} The failed Typeable derivation also causes the Show derivation to fail, which causes an error later in the file. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10684> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #13168: Ambiguous interface errors in GHCi, even with -XPackageImports
by GHC 25 Jul '17

25 Jul '17

#13168: Ambiguous interface errors in GHCi, even with -XPackageImports -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.2 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: -------------------------------------+------------------------------------- Originally reported in https://github.com/haskell/cabal/issues/4253, but I moved it here after being reassured that this was a GHCi bug, not a `Cabal` one. To reproduce this issue, you'll need to install two libraries that export two constructors with the same name. The original issue uses `GLFW` and `GLFW-b` as examples, but for the puposes of test case minimalization, I've prepared a repo here (https://github.com/RyanGlScott/cabal-gh4253) with as small of an example as I can manage. To reproduce the issue, do the following: {{{ $ git clone https://github.com/RyanGlScott/cabal-gh4253 $ cd cabal-gh4253/ $ cabal install package1/ package2/ $ ghci -XPackageImports GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci λ> import "package1" DuplicateModuleName λ> Window <interactive>:1:1: error: Ambiguous interface for ‘DuplicateModuleName’: it was found in multiple packages: package1-0.1.0.0 package2-0.1.0.0 }}} This seems to be specific to GHCi, because I cannot find a way to trigger the same issue with `ghc --make`. I've reproduced this with GHC 8.0.2 and HEAD. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13168> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #10064: Add support for "foo"## literals to MagicHash
by GHC 24 Jul '17

24 Jul '17

#10064: Add support for "foo"## literals to MagicHash -------------------------------------+------------------------------------- Reporter: chadaustin | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.4 Component: Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- I'm working on a high-performance library for building up buffers of data. Appending ByteStrings works pretty well, but, for bytestring literals, it's faster to avoid the CAF (and it's associated tag check + indirect jump) entirely and append a zero-terminate MagicHash string literal via Addr#. Then I discovered that it's 30% faster if you can avoid the strlen with an explicit length. See this benchmark: https://github.com/chadaustin /buffer- builder/blob/ac662962d6d3c21f206ab8e8121323b9f18677fa/bench/Bench.hs#L42 That API is not very pleasant, of course. :) Thus, here is a feature request: It would be great if "foo"## produced (# Int#, Addr# #), where the Int# is the length of the buffer in bytes. The compiler could enforce that the literal only contains 8-bit values. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10064> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #9453: The example for GHC Generics is kinda broken
by GHC 24 Jul '17

24 Jul '17

#9453: The example for GHC Generics is kinda broken -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- From http://www.reddit.com/r/haskell/comments/2douzn/problem_with_popular_ghcgen…: The popular GHC.Generics serialization example at http://www.haskell.org/ghc/docs/latest/html/users_guide/generic- programming.html#idp25226064 illustrates how to serialize a sum datatype (a :+: b), with a 0 bit representing a and a 1 bit representing b. However, consider a :+: b :+: c. If the compiler treats this as (a :+: b) :+: c, then a is 00, b is 01, c is 1. If it's a :+: (b :+: c), then a is 0, b is 10, c is 11. The compiler's decision, even though (as I understand it) consistent for any given compile, could differ later. The manual, at http://hackage.haskell.org/package/generic- deriving-1.6.3/docs/Generics-Deriving-Base.html#g:9 states not to depend on the ordering, which the example does. I think this is a valid concern, and the manual should be at least updated to discuss this problem. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9453> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #13304: GHC 8.0.* is slow when run on Windows 10 Ubuntu subsystem
by GHC 24 Jul '17

24 Jul '17

#13304: GHC 8.0.* is slow when run on Windows 10 Ubuntu subsystem -------------------------------------+------------------------------------- Reporter: sukhmel | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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 tried both 8.0.1 and 8.0.2 versions of GHC. 7.10.3 runs just fine. Installation process is also much faster for 7.10.3, later versions have taken around 4 hours to be installed. Programs compiled with slow GHC are also slow. Sample program: {{{#!haskell main = putStrLn "Hello, world!" }}} GHC is installed with Stack. Windows version is 1607 build 15031.0 I believe this could be a bug in implementation of Ubuntu subsystem, but I'm not quite sure what part of it is failing. {{{ $ time stack ghc -- -e 'putStrLn ""' real 2m28.240s user 0m0.375s sys 3m30.078s $ time stack ghc -- --version The Glorious Glasgow Haskell Compilation System, version 8.0.2 real 1m45.533s user 0m0.125s sys 2m46.516s time stack ghc --compiler ghc-8.0.1 -- --version The Glorious Glasgow Haskell Compilation System, version 8.0.1 real 2m54.764s user 0m0.234s sys 3m58.422s }}} {{{ $ time ghc -e 'putStrLn ""' real 0m0.872s user 0m0.109s sys 0m0.125s $ time ghc --version The Glorious Glasgow Haskell Compilation System, version 7.6.3 real 0m0.072s user 0m0.000s sys 0m0.031s time stack ghc --compiler ghc-7.10.3 -- -e 'putStrLn ""' real 0m0.876s user 0m0.234s sys 0m0.688s time stack ghc --compiler ghc-7.10.3 -- --version The Glorious Glasgow Haskell Compilation System, version 7.10.3 real 0m0.832s user 0m0.109s sys 0m0.813s }}} {{{ $ echo 'main = putStrLn "Hello, world!"' > test.hs $ time stack ghc --compiler ghc-8.0.2 -- test [1 of 1] Compiling Main ( test.hs, test.o ) Linking test ... real 3m56.582s user 0m0.609s sys 5m8.125s $ time ./test Hello, world! real 0m27.540s user 0m0.000s sys 0m27.297s }}} {{{ $ echo 'main = putStrLn "Hello, world!"' > test.hs $ time stack ghc --compiler ghc-7.10.3 -- test [1 of 1] Compiling Main ( test.hs, test.o ) Linking test ... real 0m2.222s user 0m0.406s sys 0m1.406s $ time ./test Hello, world! real 0m0.030s user 0m0.000s sys 0m0.031s }}} Part of Stack output with timings: {{{ $ stack ghc --verbose -- -e 'putStrLn "Hello, world!"' Version 1.3.2, Git revision 3f675146590da4f3edf768b89355f798229da2a5 (4395 commits) x86_64 hpack-0.15.0 ... 2017-02-19 21:13:05.756085: [debug] No project config file found, using defaults. 2017-02-19 21:13:05.759402: [debug] Run from outside a project, using implicit global project config 2017-02-19 21:13:05.761724: [debug] Using resolver: lts-8.0 from implicit global project's config file: /home/sukhmel/.stack/global- project/stack.yaml ... 2017-02-19 21:13:05.788855: [debug] Run process: /sbin/ldconfig -p 2017-02-19 21:13:05.816489: [debug] Process finished in 26ms: /sbin/ldconfig -p 2017-02-19 21:13:05.820648: [debug] Run process: /usr/bin/gcc -v 2017-02-19 21:13:05.844975: [debug] Process finished in 23ms: /usr/bin/gcc -v ... 2017-02-19 21:13:05.854997: [debug] Using standard GHC build 2017-02-19 21:13:05.856774: [debug] Getting global package database location ... 2017-02-19 21:13:05.867711: [debug] Run process: /home/sukhmel/.stack/programs/x86_64-linux/ghc-8.0.2/bin/ghc-pkg --no- user-package-db list --global 2017-02-19 21:13:05.888957: [debug] Run process: /home/sukhmel/.stack/programs/x86_64-linux/ghc-8.0.2/bin/ghc --numeric- version 2017-02-19 21:13:05.919968: [debug] Run process: /home/sukhmel/.stack/programs/x86_64-linux/ghc-8.0.2/bin/ghc-pkg --no- user-package-db field --simple-output Cabal version 2017-02-19 21:13:38.605653: [debug] Process finished in 32736ms: /home/sukhmel/.stack/programs/x86_64-linux/ghc-8.0.2/bin/ghc-pkg --no- user-package-db list --global 2017-02-19 21:14:11.930034: [debug] Process finished in 32792ms: /home/sukhmel/.stack/programs/x86_64-linux/ghc-8.0.2/bin/ghc-pkg --no- user-package-db field --simple-output Cabal version 2017-02-19 21:14:11.931071: [debug] Process finished in 32831ms: /home/sukhmel/.stack/programs/x86_64-linux/ghc-8.0.2/bin/ghc --numeric- version ... 2017-02-19 21:14:11.939817: [debug] Run process: /home/sukhmel/.stack/programs/x86_64-linux/ghc-8.0.2/bin/ghc -e "putStrLn \"Hello, world!\"" }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13304> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #13375: ghc-pkg "cache is out of date" message breaks testsuite
by GHC 23 Jul '17

23 Jul '17

#13375: ghc-pkg "cache is out of date" message breaks testsuite -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: ghc-pkg | Version: 8.0.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: -------------------------------------+------------------------------------- Since the merge of the package database locking business, `ghc-pkg dump` spews a message on `stderr` on Windows, {{{ $ "C:/msys64/home/ben/ghc/inplace/bin/ghc-pkg.exe" dump WARNING: cache is out of date: C:\msys64\home\ben\ghc\inplace\lib\package.conf.d\package.cache ghc will see an old view of this package db. Use 'ghc-pkg recache' to fix. name: xhtml version: 3000.2.1 id: xhtml-3000.2.1 ... }}} When the testsuite driver sees this it (namely `testutil.getStdout`) assumes something has gone terribly wrong and aborts. From a cursory look it's not clear how we got into this situation; the file indeed exists and was certainly touched during the build. However, running `ghc-pkg recache` indeed seems to fix the issue. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13375> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 19