August 2016 - ghc-tickets

[GHC] #11799: Legend for hpc markup colors
by GHC 04 May '17

04 May '17

#11799: Legend for hpc markup colors -------------------------------------+------------------------------------- Reporter: drathier | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Test Suite | Version: 7.10.3 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: -------------------------------------+------------------------------------- The hpc markup colors are not documented anywhere. Coming from an imperative background, red means never executed and green means executed at least once. Here, green means always true, red means always false, yellow means never executed. Adding a one-line legend at the top of the output file(s) describing the colours would help a lot. Suggesting `never executed` `always true` and `always false` on a single line at the top with the same yellow, green and red background as the respective highlighted code would have. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11799> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #11616: Kinds aren't instantiated
by GHC 04 May '17

04 May '17

#11616: Kinds aren't instantiated -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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: -------------------------------------+------------------------------------- {{{#!hs {-# LANGUAGE TypeInType, AllowAmbiugousTypes #-} class Whoami a where whoami :: String instance Whoami Int where whoami = "int" instance Whoami Bool where whoami = "[y/n]" instance Whoami Maybe where whoami = "call me maybe" }}} we can write {{{ >>> whoami @Type @Int "int" >>> whoami @Type @Bool "[y/n]" >>> whoami @(Type -> Type) @Maybe "call me maybe" }}} Attempting to specialise `whoami` to `Type` we can't simply write `whoamiType = whoami @Type` as one might expect. To start we define a synonym: {{{ $ ghci -ignore-dot-ghci /tmp/t17q.hs GHCi, version 8.1.20160117: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( /tmp/t17q.hs, interpreted ) Ok, modules loaded: Main. *Main> whoami2 = whoami <interactive>:1:1: error: • Ambiguous type variable ‘a0’ arising from a use of ‘whoami’ prevents the constraint ‘(Whoami a0)’ from being solved. Probable fix: use a type annotation to specify what ‘k0’, ‘a0’ should be. These potential instances exist: three instance involving out-of-scope typess (use -fprint-potential-instances to see them all) • When instantiating ‘whoami2’, initially inferred to have this overly-general type: forall k (a :: k). Whoami a => String NB: This instantiation can be caused by the monomorphism restriction. }}} Using the “overly-general” inferred type `whoami :: forall k (a :: k). Whoami a => String` fails: {{{#!hs -- • Could not deduce (Whoami a0) arising from a use of ‘whoami’ -- from the context: Whoami a -- bound by the type signature for: -- whoami2 :: Whoami a => String -- at /tmp/t17q.hs:20:1-44 -- The type variable ‘a0’ is ambiguous -- These potential instances exist: -- three instance involving out-of-scope typess -- (use -fprint-potential-instances to see them all) -- • In the expression: whoami -- In an equation for ‘whoami2’: whoami2 = whoami whoami2 :: forall k (a :: k). Whoami a => String whoami2 = whoami }}} so we need `TypeApplications`: {{{#!hs whoami2 :: forall k (a :: k). Whoami a => String whoami2 = whoami @_ @a }}} and then we can write: {{{#!hs whoamiType :: forall (a :: Type). Whoami a => String whoamiType = whoami @_ @a }}} and we can write as intended: {{{ >>> whoamiType @Int "int" >>> whoamiType @Bool "[y/n]" }}} Is there a reason one cannot write: {{{#!hs whoami2 = whoami whoamiType = whoami @Type }}} ---- As a side note, what is the difference between {{{#!hs -- >>> :set -fprintf-explicit-foralls -- >>> :kind Whoami1 -- Whoami1 :: forall {k}. k -> Constraint -- >>> :kind Whoami2 -- Whoami2 :: forall k. k -> Constraint class Whoami1 a class Whoami2 (a :: k) }}} Is there a snippet of code that highlights differences -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11616> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #11333: GHCi does not discharge satisfied constraints
by GHC 03 May '17

03 May '17

#11333: GHCi does not discharge satisfied constraints ----------------------------------------+-------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: | Operating System: Linux Architecture: Unknown/Multiple | Type of failure: Other Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+-------------------------- Don't know if this is the intended behaviour (GHCi, version 8.1.20151231), with the new extension TypeApplications. For the function [https://hackage.haskell.org/package/base-4.8.1.0/docs /Text-Show.html#v:show show]: {{{#!hs Prelude> :set -XTypeApplications Prelude> :t show show :: Show a => a -> String Prelude> :t show @Int show @Int :: Show Int => Int -> String }}} And the function [https://hackage.haskell.org/package/base/docs/Data- Typeable.html#v:eqT eqT] (`:: forall a b. (Typeable a, Typeable b) => Maybe (a :~: b)`): {{{#!hs Prelude> :set -XTypeApplications Prelude> import Data.Typeable Prelude Data.Typeable> :t eqT eqT :: forall k1 (a :: k1) (b :: k1). (Typeable a, Typeable b) => Maybe (a :~: b) Prelude Data.Typeable> :t eqT eqT :: forall k1 (a :: k1) (b :: k1). (Typeable a, Typeable b) => Maybe (a :~: b) Prelude Data.Typeable> :t eqT @Int eqT @Int :: (Typeable Int, Typeable b) => Maybe (Int :~: b) }}} Should the types of `show @Int` and `eqT @Int` not be `Int -> String` and `(Typeable b) => Maybe (Int :~: b)` respectively? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11333> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #11669: Incorrectly suggests RankNTypes for ill-formed type "forall a. Eq a. Int"
by GHC 03 May '17

03 May '17

#11669: Incorrectly suggests RankNTypes for ill-formed type "forall a. Eq a. Int" -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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: -------------------------------------+------------------------------------- {{{ baldur@Loki:~$ ghci -ignore-dot-ghci GHCi, version 8.1.20160117: http://www.haskell.org/ghc/ :? for help Prelude> let foo :: forall a. Eq a. Int; foo = undefined <interactive>:1:20: error: Illegal symbol '.' in type Perhaps you intended to use RankNTypes or a similar language extension to enable explicit-forall syntax: forall <tvs>. <type> Prelude> :set -XRankNTypes Prelude> let foo :: forall a. Eq a. Int; foo = undefined <interactive>:3:26: error: Illegal symbol '.' in type Perhaps you intended to use RankNTypes or a similar language extension to enable explicit-forall syntax: forall <tvs>. <type> Prelude> }}} also {{{ Prelude> :kind forall a. Eq a. Int <interactive>:1:15: error: Illegal symbol '.' in type Perhaps you intended to use RankNTypes or a similar language extension to enable explicit-forall syntax: forall <tvs>. <type> }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11669> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #10230: multiline literals doesn't work with CPP extension.
by GHC 02 May '17

02 May '17

#10230: multiline literals doesn't work with CPP extension. -------------------------------------+------------------------------------- Reporter: qnikst | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- If LANGUAGE CPP is enabled then multiline literals stops working. Steps to reproduce. 1. write a program with multiline literal: cat 1.hs {{{#!hs test = "mutli\ \line" main = putStrLn test }}} 2. it should compile without CPP: ghc 1.hs [1 of 1] Compiling Main ( 1.hs, 1.o ) Linking 1 ... 3. compile it with CPP extension Expected result: program compiles {{{ ghc 1.hs [1 of 1] Compiling Main ( 1.hs, 1.o ) Linking 1 ... }}} Actual result: compilation breaks {{{ ghc -XCPP 1.hs [1 of 1] Compiling Main ( 1.hs, 1.o ) [flags changed] 1.hs:1:18: lexical error in string/character literal at character 'l' }}} At least ghc-7.8.4 and ghc-7.10 are affected. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10230> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #8443: cannot find normal object file when compiling TH code
by GHC 01 May '17

01 May '17

#8443: cannot find normal object file when compiling TH code ----------------------------+---------------------------------------------- Reporter: snoyberg | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: GHC rejects valid program (amd64) | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | ----------------------------+---------------------------------------------- Unfortunately, I haven't been able to whittle this down to a smaller test case. In order to reproduce, just run `cabal install yesod-core-1.2.4.5 --enable-tests`. The result is: {{{ test/YesodCoreTest/NoOverloadedStrings.hs:16:26: cannot find normal object file ‛dist/build/tests/tests- tmp/YesodCoreTest/NoOverloadedStringsSub.dyn_o’ while linking an interpreted expression }}} Tested using: The Glorious Glasgow Haskell Compilation System, version 7.7.20131012 cabal-install version 1.18.0.2 using version 1.18.0 of the Cabal library I'm on Ubuntu 12.04 64-bit. Compiling with GHC 7.6.3 and 7.4.2 works correctly. Let me know if there's any other information I can provide. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8443> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #12104: Type families, `TypeError`, and `-fdefer-type-errors` cause "opt_univ fell into a hole"
by GHC 28 Apr '17

28 Apr '17

#12104: Type families, `TypeError`, and `-fdefer-type-errors` cause "opt_univ fell into a hole" -------------------------------------+------------------------------------- Reporter: antalsz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: TypeFamilies, | Operating System: MacOS X CustomTypeErrors | Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- If I create a type family – open or closed – with a case that evaluates to a `TypeError`, and define a top-level binding with this type, loading the file with `-fdefer-type-errors` enabled (or via `:load!`/`:reload!`) panics GHC with "opt_univ fell into a hole". (And if I used `:load!` or `:reload!`, `-fdefer-type-errors` doesn't get unset.) A minimal example: {{{#!hs {-# LANGUAGE TypeFamilies, DataKinds, UndecidableInstances #-} import GHC.TypeLits type family F a where F a = TypeError (Text "error") err :: F () err = () }}} results in the panic {{{ ….hs:9:7: warning: [-Wdeferred-type-errors] • error • In the expression: () In an equation for ‘err’: err = () ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-apple-darwin): opt_univ fell into a hole {a4Va} }}} Adding more cases to the type family, or making it open, still cause the crash. This holds whether the error case is a final catch-all case, or something more like {{{#!hs type family F a where F () = TypeError (Text "error") F a = () }}} Just using a type synonym for `F` doesn't cause a panic, however, and nor does giving `err` the type `TypeError (Text "error")` directly. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12104> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #11821: Internal error: not in scope during type checking, but it passed the renamer
by GHC 28 Apr '17

28 Apr '17

#11821: Internal error: not in scope during type checking, but it passed the renamer -------------------------------------+------------------------------------- Reporter: darchon | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc3 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: -------------------------------------+------------------------------------- While trying to get the singletons package to compile on GHC8 (https://github.com/goldfirere/singletons/pull/142) I encountered the following error while trying to track down a bug: {{{ [1 of 1] Compiling NotInScope ( NotInScope.hs, interpreted ) NotInScope.hs:22:20: error: • GHC internal error: ‘b’ is not in scope during type checking, but it passed the renamer tcl_env of environment: [a1lm :-> Type variable ‘b’ = b, a1lA :-> Type variable ‘l1’ = l1, a1lB :-> Type variable ‘l2’ = l2, a1lC :-> Type variable ‘l3’ = l3, a1lE :-> Type variable ‘a’ = a, a1lF :-> Type variable ‘l4’ = l4, r1aq :-> ATcTyCon Lgo, r1aG :-> ATcTyCon Lgo1, r1aI :-> ATcTyCon Lgo2] • In the kind ‘b’ In the definition of data constructor ‘Lgo1KindInference’ In the data declaration for ‘Lgo1’ }}} for the following code: {{{ {-# LANGUAGE RankNTypes, DataKinds, PolyKinds, GADTs, TypeFamilies, UndecidableInstances #-} module NotInScope where import Data.Proxy type KindOf (a :: k) = ('KProxy :: KProxy k) data TyFun :: * -> * -> * type family Apply (f :: TyFun k1 k2 -> *) (x :: k1) :: k2 data Lgo2 l1 l2 l3 (l4 :: b) (l5 :: TyFun [a] b) = forall (arg :: [a]) . KindOf (Apply (Lgo2 l1 l2 l3 l4) arg) ~ KindOf (Lgo l1 l2 l3 l4 arg) => Lgo2KindInference data Lgo1 l1 l2 l3 (l4 :: TyFun b (TyFun [a] b -> *)) = forall (arg :: b) . KindOf (Apply (Lgo1 l1 l2 l3) arg) ~ KindOf (Lgo2 l1 l2 l3 arg) => Lgo1KindInference type family Lgo f z0 xs0 (a1 :: b) (a2 :: [a]) :: b where Lgo f z0 xs0 z '[] = z Lgo f z0 xs0 z ('(:) x xs) = Apply (Apply (Lgo1 f z0 xs0) (Apply (Apply f z) x)) xs }}} Note that the above code works fine in GHC 7.10.2. There are two options to make the code compile on GHC8-rc3: * Remove the kind annotations on the {{{forall arg .}}} binders * Or make the following changes using TypeInType: {{{ {-# LANGUAGE RankNTypes, DataKinds, PolyKinds, GADTs, TypeFamilies, UndecidableInstances, TypeInType #-} module NotInScope where import Data.Proxy import GHC.Types type KindOf (a :: k) = ('KProxy :: KProxy k) data TyFun :: * -> * -> * type family Apply (f :: TyFun k1 k2 -> *) (x :: k1) :: k2 data Lgo2 a b l1 l2 l3 (l4 :: b) (l5 :: TyFun [a] b) = forall (arg :: [a]) . KindOf (Apply (Lgo2 a b l1 l2 l3 l4) arg) ~ KindOf (Lgo a b l1 l2 l3 l4 arg) => Lgo2KindInference data Lgo1 a b l1 l2 l3 (l4 :: TyFun b (TyFun [a] b -> *)) = forall (arg :: b) . KindOf (Apply (Lgo1 a b l1 l2 l3) arg) ~ KindOf (Lgo2 a b l1 l2 l3 arg) => Lgo1KindInference type family Lgo a b f z0 xs0 (a1 :: b) (a2 :: [a]) :: b where Lgo a b f z0 xs0 z '[] = z Lgo a b f z0 xs0 z ('(:) x xs) = Apply (Apply (Lgo1 a b f z0 xs0) (Apply (Apply f z) x)) xs }}} I'm sorry I didn't create a smaller test case. Let me know if one is required and I'll try. The error seems to be related to the recursive aspect of the three definitions and how implicit kind variables are handled in ghc8. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11821> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

[GHC] #8996: mark more things as const in C codegen
by GHC 24 Apr '17

24 Apr '17

#8996: mark more things as const in C codegen -------------------------------------------+------------------------------- Reporter: slyfox | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (CodeGen) | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 hour) | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: -------------------------------------------+------------------------------- Recently i've tried to build ghc-7.8.2 on ia64 and it overflows so called "short data" section. (it's where global 'static' variables live). I've looked at low-hanging fruits of squashing such global "variables". One source of them seems to be a string literal. Consider one-line module: {{{ module B (v) where v = "hello" }}} in '''-fvia-C''' (or unreg) mode it generates code like {{{ static char gibberish_str[] = "hello"; }}} It uselessly eats data section. The patch switches generator to emit: {{{ static const char gibberish_str[] = "hello"; }}} Some notes: 1. as far as I see native codegens already put ot to .rodata, thus it should be safe. 2. I likely didn't cover more cases, like - RelocatableReadOnlyData - and mysterious '''pprTop (CmmData _section (Statics lbl [CmmUninitialised size]))''' Size of unreg-stage2 on amd64 before and after the patch: {{{ $ size inplace/lib/bin/ghc-stage2 (unpatched) text data bss dec hex filename 81986382 20776344 44096 102806822 620b526 inplace/lib/bin/ghc-stage2 $ size inplace/lib/bin/ghc-stage2 (patched) text data bss dec hex filename 83648494 19062936 44096 102755526 61fecc6 inplace/lib/bin/ghc-stage2 }}} Text section increased for 1.6MBs (consts moved here, likely .rodata actually), data section decreased for 1.7MBs. I think with minor fiddling with linker flags we can merge equal constants later on. Thanks! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8996> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #11714: Kind of (->) type constructor is overly constrained
by GHC 24 Apr '17

24 Apr '17

#11714: Kind of (->) type constructor is overly constrained -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: feature | Status: new request | Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.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: -------------------------------------+------------------------------------- Currently the `(->)` type constructor has kind `* -> * -> *` (with some magic to make infix work for unlifted types. To quote the comment attached to `TysPrim.funTyCon`, > You might think that `(->)` should have type `?? -> ? -> *`, and you'd be right. But if we do that we get kind errors when saying > {{{ > instance Control.Arrow (->) > }}} > because the expected kind is `* -> * -> *`. The trouble is that the expected/actual stuff in the unifier does not go contra-variant, whereas the kind sub-typing does. Sigh. It really only matters if you use `(->)` in a prefix way, thus: `(->) Int# Int#`. And this is unusual. because they are never in scope in the source }}} This seems to imply that the restrictive kind arose out of the old subkinding story. Now that we have a more principled way of dealing with non-lifted kinds it seems we allow prefix uses to be as polymorphic as infix uses. Something like, {{{#!hs (->) :: forall (rep1 :: RuntimeRep) (rep2 :: RuntimeRep). TYPE rep1 -> TYPE rep2 -> * }}} Not only would this be a win for consistency, but it may also address some of the Core Lint issues that I'm seeing in #11011. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11714> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15