September 2016 - ghc-tickets

[GHC] #10431: EqualityConstraints extension?
by GHC 06 May '17

06 May '17

#10431: EqualityConstraints extension? -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: Type: feature | Status: new request | Milestone: 7.12.1 Priority: normal | Version: 7.11 Component: Compiler | Operating System: Unknown/Multiple (Type checker) | Type of failure: None/Unknown Keywords: | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- At the moment, writing an equality constraint in a type requires at least one of the `GADTs` or `TypeFamilies` extensions. However, each of these has other effects. Could we have an `EqualityConstraints` extension to permit equality constraints in types, but neither GADTs nor type families? Presumably this extension should imply `MonoLocalBinds`. The `GADTs` extension could then become precisely the conjunction of `GADTSyntax`, `EqualityConstraints` and `ExistentialQuantification`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10431> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #12156: -fdefer-typed-holes causes panic on unbound variable
by GHC 06 May '17

06 May '17

#12156: -fdefer-typed-holes causes panic on unbound variable -------------------------------------+------------------------------------- Reporter: osa1 | Owner: Type: bug | Status: new Priority: high | 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: -------------------------------------+------------------------------------- {{{#!haskell module Main where main = do print v return () }}} Compile it without {{{-fdefer-typed-holes}}} and it fails as expected: {{{ ➜ hole_bug ghc --make Main.hs -fforce-recomp [1 of 1] Compiling Main ( Main.hs, Main.o ) Main.hs:4:11: error: Variable not in scope: v }}} Adding {{{-fdefer-typed-holes}}} is causing a panic instead of runtime error: {{{ ➜ hole_bug ghc --make Main.hs -fforce-recomp -fdefer-typed-holes [1 of 1] Compiling Main ( Main.hs, Main.o ) Main.hs:4:11: warning: [-Wtyped-holes] Variable not in scope: v ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-unknown-linux): StgCmmEnv: variable not found $dShow_aKo local binds for: $trModule $trModule1_r16k $trModule2_r16s sat_s16x sat_s16z Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Tried with: 8.0.1, HEAD as of today. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12156> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #9557: Deriving instances is slow
by GHC 06 May '17

06 May '17

#9557: Deriving instances is slow -------------------------------------+------------------------------------- Reporter: Feuerbach | 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: -------------------------------------+------------------------------------- Let's take [https://raw.githubusercontent.com/haskell-suite/haskell-src- exts/8e0153d33b66add96fd5606614ce7938d2029510/src/Language/Haskell/Exts/Annotated/Syntax.hs this file] (from haskell-src-exts) and build it with -O0. On my machine it takes 55s. If we remove deriving of all classes except Functor (which is the only one used by the module itself), the time will drop down to 4s. Different classes vary in their compile-time cost, but there's no single culprit. Among the costly ones are Generic, Data, Show, Ord. haskell-src-exts users are very annoyed by its long compile time, about 10 minutes, especially because we don't compile with -O0 by default. It would be nice to get this fixed. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9557> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 24

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

05 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 05 May '17

05 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