January 2016 - ghc-tickets

[GHC] #10963: Beginner-targeted language extension
by GHC 29 Aug '16

29 Aug '16

#10963: Beginner-targeted language extension -------------------------------------+------------------------------------- Reporter: kanetw | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 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: -------------------------------------+------------------------------------- FMP significantly complicated type signatures such as `length :: Foldable t => t a -> Int`, which makes teaching Haskell more difficult. I propose a language extension `-XBeginner` which instructs GHC(i) to specialize `Foldable` and `Traversable` to `[]` when possible and in case of an ambiguous instance, default those to `[]`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10963> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 25

[GHC] #10547: feature request: expanding type synonyms in error messages
by GHC 26 Aug '16

26 Aug '16

#10547: feature request: expanding type synonyms in error messages -------------------------------------+------------------------------------- Reporter: osa1 | Owner: osa1 Type: feature | Status: new request | Milestone: 7.12.1 Priority: low | Version: 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: | -------------------------------------+------------------------------------- Type errors sometimes becoming confusing because of synonyms, for example, expected type and found type sometimes use different synonyms or sometimes only one of them use a synonym etc. We discussed this in the mailing list: https://mail.haskell.org/pipermail /ghc-devs/2015-June/009247.html And also moved it to the Wiki to collect examples: https://wiki.haskell.org/Expanding_type_synonyms_in_error_messages_proposal I'm currently working on a patch, I made some progress and I'll hopefully submit something for reviews in a couple of days. This ticket is for further discussions and keep track of the progress. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10547> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 23

[GHC] #11442: Segfault when showing (undefined :: Type)
by GHC 26 Aug '16

26 Aug '16

#11442: Segfault when showing (undefined :: Type) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This [https://ghc.haskell.org/trac/ghc/ticket/11311?replyto=3#comment:3 comment] made me wonder about the relationship between `Void` and `Type`, `id :: Void -> Void` and `id :: Type -> Type`: https://ghc.haskell.org/trac/ghc/ticket/11311?replyto=3#comment:3 {{{#!hs {-# LANGUAGE TypeSynonymInstances, FlexibleInstances #- import Data.Kind (Type) instance Show Type where show _ = "..." main = print (undefined :: Type) }}} running gives: {{{ $ runghc --version runghc 8.1.20160113 $ runghc -ignore-dot-ghci Segfault.hs Segmentation fault (core dumped) }}} Verbose log attached. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11442> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #11443: SPECIALIZE pragma does not work + performance drop in GHC 8.0-rc1
by GHC 25 Aug '16

25 Aug '16

#11443: SPECIALIZE pragma does not work + performance drop in GHC 8.0-rc1 -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.1-rc1 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: -------------------------------------+------------------------------------- Hello! I've just hit a strange issue. I might missinterpret how the `SPECIALIZE` pragma works, but if I understand correctly, then there is a bug in GHC. Lets consider this simple code: module `A`: {{{ {-# LANGUAGE UndecidableInstances #-} {-# LANGUAGE TypeOperators #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE DataKinds #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE FlexibleInstances #-} module A where import Prelude import GHC.TypeLits -- TF utils type family (a :: Nat) :== (b :: Nat) where a :== a = 'True a :== b = 'False type family If cond (a :: Nat) (b :: Nat) where If 'True a b = a If 'False a b = b -- Heavy TF computations type family HeavyTF (n :: Nat) (i :: Nat) :: Nat where HeavyTF n 0 = 0 HeavyTF n i = If (HeavyTF' n :== 0) (HeavyTF n (i - 1)) 1 type family HeavyTF' (n :: Nat) :: Nat where HeavyTF' 0 = 0 HeavyTF' n = HeavyTF' (n - 1) -- Params for tests (bigger numbers = longer compile times) type family NatOf a :: Nat type instance NatOf Int = 12000 type instance NatOf String = 12000 -- Type class to check GHC behavior class PerfC1 a where perfc1 :: a -> String instance CheckOk (HeavyTF 10 (NatOf a)) => PerfC1 a where perfc1 _ = "oh" ; {-# INLINABLE perfc1 #-} class CheckOk (n :: Nat) instance CheckOk 0 -- where main_cache :: IO () main_cache = do print $ perfc1 (1 :: Int) print $ perfc1 ("a" :: String) perfc1_Int :: Int -> String perfc1_Int = perfc1 perfc1_String :: String -> String perfc1_String = perfc1 {-# SPECIALIZE perfc1 :: Int -> String #-} {-# SPECIALIZE perfc1 :: String -> String #-} ----- perfc1' :: PerfC1 a => a -> String perfc1' = perfc1 {-# INLINABLE perfc1' #-} {-# SPECIALIZE perfc1' :: Int -> String #-} {-# SPECIALIZE perfc1' :: String -> String #-} }}} module `Test1`: {{{ import A main = do print $ perfc1 (1 :: Int) print $ perfc1 ("a" :: String) }}} module `Test2`: {{{ import A main = do print $ perfc1' (1 :: Int) print $ perfc1' ("a" :: String) }}} module `Test3`: {{{ import A main = do print $ perfc1_Int (1 :: Int) print $ perfc1_String ("a" :: String) }}} Compile with: `ghc 7.10.3` : `ghc -O2 -fenable-rewrite-rules Test<n>.hs` `ghc 8.0-rc1` : `ghc -O2 -fenable-rewrite-rules -freduction-depth=0 Test<n>.hs` If module `A` was already compiled the compilation times for `ghc 7.10.3` were as follow: - `Test1`: ~ 16s - `Test2`: ~ 16s - `Test3`: almost instant And for `ghc 8.0-rc1` were as follow: - `Test1`: ~ 28s - `Test2`: ~ 28s - `Test3`: almost instant Here are 2 bugs to note: 1) the compilation times are much longer with new GHC 2) the specialize pragmas do not work -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11443> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

[GHC] #11484: Type synonym using -XTypeInType can't be spliced with TH
by GHC 25 Aug '16

25 Aug '16

#11484: Type synonym using -XTypeInType can't be spliced with TH -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 8.0.1-rc1 Haskell | Keywords: TypeInType | 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: -------------------------------------+------------------------------------- The following code compiles: {{{#!hs {-# LANGUAGE TemplateHaskell #-} {-# LANGUAGE TypeInType #-} {-# OPTIONS_GHC -ddump-splices #-} module Foo where import Data.Kind type TySyn (k :: *) (a :: k) = () -- $([d| type TySyn2 (k :: *) (a :: k) = () |]) }}} But uncomment the last line, and it doesn't compile: {{{ $ /opt/ghc/head/bin/ghc Foo.hs [1 of 1] Compiling Foo ( Foo.hs, Foo.o ) Foo.hs:10:3-43: Splicing declarations [d| type TySyn2_aBH (k_aBI :: *) (a_aBJ :: k_aBI) = () |] ======> type TySyn2_a4BF (k_a4BG :: Type) (a_a4BH :: k_a4BG) = () Foo.hs:10:3: error: • Couldn't match expected kind ‘GHC.Prim.Any’ with actual kind ‘k1’ • In the type declaration for ‘TySyn2’ Foo.hs:10:3: error: • Kind variable ‘k_a4BG’ is implicitly bound in datatype ‘TySyn2’, but does not appear as the kind of any of its type variables. Perhaps you meant to bind it (with TypeInType) explicitly somewhere? Type variables with inferred kinds: k_a4BG (a_a4BH :: GHC.Prim.Any) • In the type declaration for ‘TySyn2’ }}} There are two issues here: 1. The error message claims that `TySyn2` is a datatype when it is actually a type synonym. This should be easy enough to fix; just change [http://git.haskell.org/ghc.git/blob/89bdac7635e6ed08927d760aa885d3e7ef3edb8… the code] that throws the error message to invoke [http://git.haskell.org/ghc.git/blob/89bdac7635e6ed08927d760aa885d3e7ef3edb8… tyConFlavour]. 2. For some reason, the type variable `a` in `TySyn2` fails to kind-check. Somehow, an `Any` got in there, but I'm not sure where it snuck in. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11484> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #11072: Runtime linker doesn't search for DLLs referenced in import libraries on Windows
by GHC 25 Aug '16

25 Aug '16

#11072: Runtime linker doesn't search for DLLs referenced in import libraries on Windows -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Phyx- Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2-rc2 (Linking) | Keywords: | Operating System: Windows Architecture: | Type of failure: Runtime crash Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- (This is adapted from the comments [https://github.com/bos/text- icu/issues/12#issuecomment-154452774 here].) On Windows, the GHC runtime linker only searches for DLLs that have the same names as the import libraries passed to `-l`. This can sometimes create problems, since a library name could be different from the DLL it needs. `text-icu` provides an example of this, since it needs the extra libraries `icuuc`, `icudt`, and `icuin`. However, if you download the [http://site .icu-project.org/download/56#TOC-ICU4C-Download official ICU 56 binaries], they are distributed with DLLs named `icuuc56.dll`, `icudt56.dll`, and `icuin56.dll`, rather than `icuuc.dll`, `icudt.dll`, and `icuin.dll`. This doesn't create any trouble for the linker at compile-time. In fact, if you compile this program {{{#!hs -- TextICU.hs import Data.Text.ICU.Break main = print Kana }}} with `ghc TextICU.hs` and then run `cygcheck ./TextICU.hs` without having the ICU4C `bin64` folder in your `PATH`, it ''appears'' to search for the right DLLs: {{{ $ cygcheck ./TextICU.hs ... cygcheck: track_down: could not find icuin56.dll cygcheck: track_down: could not find icuuc56.dll }}} But actually running the code reveals a different story: {{{ $ runghc TextICU.hs TextICU.hs: icuuc: The specified module could not be found. TextICU.hs: <command line>: can't load .so/.DLL for: icuuc.dll (addDLL: could not load DLL) }}} This demonstrates that the runtime linker behaves differently; it is dependent on what the linked libraries' names are. To confirm this, you can recompile `text-icu` with the following changes to `text-icu.cabal`: {{{ extra-libraries: icuuc56 if os(mingw32) extra-libraries: icuin56 icudt56 }}} Also make symlinks named `icuuc56.lib`, `icuin56.lib`, and `icudt56.lib` that refer to `icuuc.lib`, `icuin.lib`, and `licudt.lib`, respectively, in the ICU4C `lib64` directory. Now `cygcheck` and `ghc` agree on which DLLs to use: {{{ $ ghc TextICU.hs $ cygcheck ./TextICU.exe ... cygcheck: track_down: could not find icuin56.dll cygcheck: track_down: could not find icuuc56.dll $ runghc TextICU.hs TextICU.hs: icuuc56: The specified module could not be found. TextICU.hs: <command line>: can't load .so/.DLL for: icuuc56.dll (addDLL: could not load DLL) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11072> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 25

[GHC] #11466: Constraint synonym with Implicit Parameter
by GHC 23 Aug '16

23 Aug '16

#11466: Constraint synonym with Implicit Parameter -------------------------------------+------------------------------------- Reporter: nomeata | 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: -------------------------------------+------------------------------------- This: {{{ {-# LANGUAGE ConstraintKinds, ImplicitParams #-} module Foo where type Foo = ?foo::() }}} gives {{{ Foo.hs:3:1: error: • Illegal implicit parameter ‘?foo::()’ • In the type synonym declaration for ‘Foo’ }}} in GHC HEAD. It used to work in GHC-7.10. Did not check GHC-8.0. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11466> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #11068: Make Generic/Generic1 methods inlinable
by GHC 23 Aug '16

23 Aug '16

#11068: Make Generic/Generic1 methods inlinable -------------------------------------+------------------------------------- Reporter: glguy | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): D1447 | Wiki Page: -------------------------------------+------------------------------------- Efficient code generation with GHC.Generics relies on the optimizer being able to completely remove the generic representation of a type. Marking these methods as inlinable ensures that this will be possible even for larger types. I'm working on techniques for transforming generically derived lenses and traversals which rely on taking advantage of the Functor and Applicative laws. This patch supports that work. https://github.com/glguy/generic-traverse -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11068> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #8955: Syscall intrinsic
by GHC 18 Aug '16

18 Aug '16

#8955: Syscall intrinsic ----------------------------------------------+---------------------------- Reporter: schyler | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Moderate (less than a day) | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: ----------------------------------------------+---------------------------- Reddit thread: http://www.reddit.com/r/haskell/comments/220ae4/libc_considered_harmful/ Mentions there are some nice things that can be done with a syscall intrinsic. Also, marginally increased speed for calling syscalls since it doesn't need to go through libffi into C-land. Should be easy to implement. llvm backend has `llvm.syscall` already. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8955> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #11385: Unify named wildcards in different type applications
by GHC 16 Aug '16

16 Aug '16

#11385: Unify named wildcards in different type applications -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.1 (Type checker) | Keywords: | Operating System: Unknown/Multiple NamedWildCards TypeApplications | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- ([https://www.reddit.com/r/haskell/comments/4030lv/unifying_distinct_type_var… motivating post]) I would like to use type application to specialize {{{#!hs Sub :: forall (a :: Constraint) (b :: Constraint). (a => Dict b) -> a :- b Sub @(Ord _a) @(Eq _a) :: forall {a}. (Ord a => Dict (Eq a)) -> Ord a :- Eq a }}} and {{{#!hs map :: forall a b. (a -> b) -> [a] -> [b] map @_a @_a :: forall {a}. (a -> a) -> [a] -> [a] }}} Is there a fundamental reason why named wildcards are not allowed to unify between type applications within the same expression? [https://downloads.haskell.org/~ghc/master/users-guide/glasgow_exts.html #named-wildcards Documentation]: > These are called named wildcards. All occurrences of the same named wildcard within one type signature will unify to the same type. I don't know if this is intended. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11385> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10