August 2017 - ghc-tickets

[GHC] #14100: Nested NPlusKPatterns
by GHC 18 Aug '17

18 Aug '17

#14100: Nested NPlusKPatterns -------------------------------------+------------------------------------- Reporter: ralf | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.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: -------------------------------------+------------------------------------- Nested patterns involving NPlusKPatterns cause a "parse error in pattern". Example appended below. > {-# LANGUAGE NPlusKPatterns #-} > {-# LANGUAGE ViewPatterns, PatternSynonyms #-} > infix 1 :^: > > data Bush elem = Nil | Bud elem | Bush elem :^: Bush elem > test ((n + 1) + 1) = n > pattern DivMod2 ∷ (Integral nat) ⇒ nat → nat → nat > pattern DivMod2 n k ← ((`divMod` 2) → (n, k)) where DivMod2 n k = 2 * n + k > braun ∷ Integer → Bush () > braun (0) = Nil > braun (1) = Bud () > braun (DivMod2 n k + 2) = braun (n + k + 1) :^: braun (n + 1) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14100> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #14136: Unsupported unicode characters crashes the program
by GHC 18 Aug '17

18 Aug '17

#14136: Unsupported unicode characters crashes the program --------------------------------------+---------------------------------- Reporter: remote | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: Runtime crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+---------------------------------- If the terminal does not support a character, the program will crash if you try to display it. {{{#!hs main = putStrLn "ms{\2205}" }}} *Lib> main ms{*** Exception: <stdout>: hPutChar: invalid argument (invalid character) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14136> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #13901: Lift the "Illegal polymorphic type" restriction on type families
by GHC 18 Aug '17

18 Aug '17

#13901: Lift the "Illegal polymorphic type" restriction on type families -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Type checker) | Keywords: TypeFamilies | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #11962 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Currently, I can do this: {{{#!hs type Foo = forall a. Maybe a }}} But if I try to refactor this to an equivalent type family: {{{#!hs type family Foo where Foo = forall a. Maybe a }}} Then GHC complains: {{{ • Illegal polymorphic type: forall a. Maybe a • In the equations for closed type family ‘Foo’ In the type family declaration for ‘Foo’ }}} We should lift this restriction. This would be necessary, for instance, to implement #11962. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13901> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #13916: Optimizations create run time seg faults
by GHC 18 Aug '17

18 Aug '17

#13916: Optimizations create run time seg faults -------------------------------------+------------------------------------- Reporter: newthin | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 (CodeGen) | Keywords: optimization | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime crash Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In the attached program, when compiling `ghc main.hs -O2`, the program immediately segfaults on run. When compiled with `ghc main.hs`, however, the program runs fine. Indeed, in our full code base it seems like even no flag is not enough, and I must explicitly begin the Bracket module with `{-# OPTIONS_GHC -O0 #-}` -- however, that may be due to stack or some other build tool. The main logic which fails is in Bracket.hs, which provides an api to convert bracket-like environment handlers (those with open/close capabilities) to caches which you can run concurrent actions against. The API allows two types of limit on the number of concurrent environments - a `Lax` limit, which will spin up additional connections if none are available, and a `Hard` limit, which caps the environment count. This seems like a detail, but if I remove the `Lax` option (as in BracketOneType), the bug goes away. With both options present, both options manifest the bug. The main.hs module is just a toy program aimed at this api, where we write 1000 lines split to arbitrary files (in a `__dir` specified on the top line - set to tmp). None of this code is important - the actual use case (which fails) is handling multiple concurrent connections to a database. The other programs (mainList, mainOneModule, and mainOneType) all appear to run correctly, and represent my attempts to create minimal cases. In particular, these respectively replace Vector with List, move all code into a single module, and get rid of the multiple options for cache types. The modules should all be the same modulo imports (or inlining) of different `Bracket` modules. I have replicated the bug on Linux, Windows, and Windows Creator Update, all with their respective versions of GHC-8.0.2. The code fails for at least vector-0.11.0.0 and vector-0.12.0.1. NB: There are times with the database access example where, worse than crashing, the program will simply return bad results. I think this might have to do with the laziness of `withEnv`, and our production version uses NFData to deepseq arguments before returning the environment to the cache - that was omitted in this test case for simplicity's sake. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13916> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 28

[GHC] #11975: New GHCi command to print out the type of an expression without instantiating
by GHC 18 Aug '17

18 Aug '17

#11975: New GHCi command to print out the type of an expression without instantiating -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: GHCi | 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: -------------------------------------+------------------------------------- #11376 changed the meaning of `:type` to deeply instantiate a type before printing. This means that we can't see which variables were specified and which were inferred. I propose `:type-spec` (please suggest a better name) that does not instantiate first. Phab patch to be posted shortly. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11975> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #11587: Place shared objects in LIBDIR
by GHC 18 Aug '17

18 Aug '17

#11587: Place shared objects in LIBDIR -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Package | Version: 7.10.3 system | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- If one compiles a program with `-dynamic`, the resulting executable includes in its `rpath` the library directory of every Haskell package that the program links against. This causes a significant number of excess system calls at program start-up. For instance, in the case of a dynamically linked `ghc` executable on Debian 8, compiling a trivial "hello world" application produces over 800 `open` calls, the majority of which originate from the dynamic linker. e.g., {{{ $ strace -f -e open ghc-7.10.3 -c -fforce-recomp Test.hs 2>&1 | grep open ... open("/usr/lib/ghc/bin/../haske_GGvi737nHHfG6zm2y7Rimi/tls/x86_64/libtinfo.so.5", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/usr/lib/ghc/bin/../haske_GGvi737nHHfG6zm2y7Rimi/tls/libtinfo.so.5", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/usr/lib/ghc/bin/../haske_GGvi737nHHfG6zm2y7Rimi/x86_64/libtinfo.so.5", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/usr/lib/ghc/bin/../haske_GGvi737nHHfG6zm2y7Rimi/libtinfo.so.5", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/usr/lib/ghc/bin/../termi_6iVf4EBnOgfIaaOCLRs8jl/tls/x86_64/libtinfo.so.5", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/usr/lib/ghc/bin/../termi_6iVf4EBnOgfIaaOCLRs8jl/tls/libtinfo.so.5", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/usr/lib/ghc/bin/../termi_6iVf4EBnOgfIaaOCLRs8jl/x86_64/libtinfo.so.5", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/usr/lib/ghc/bin/../termi_6iVf4EBnOgfIaaOCLRs8jl/libtinfo.so.5", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/usr/lib/ghc/bin/../ghc_0AG9TOjDEtx4Ji3wSwHOBe/tls/x86_64/libtinfo.so.5", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/usr/lib/ghc/bin/../ghc_0AG9TOjDEtx4Ji3wSwHOBe/tls/libtinfo.so.5", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/usr/lib/ghc/bin/../ghc_0AG9TOjDEtx4Ji3wSwHOBe/x86_64/libtinfo.so.5", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) ... }}} The dynamic linker must look in nearly 25 Haskell library directories to locate every system library! This is madness. Instead of placing each shared library in its own directory, `$LIBDIR/$PKG_KEY/lib$PKG_KEY.so` as we do currently, why not just place them in `$LIBDIR`, e.g. `$LIBDIR/libPKG_KEY.so`. This would mean that we need to include only one directory, `$LIBDIR`, in `rpath`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11587> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #11785: Kinds should be treated like types in TcSplice
by GHC 17 Aug '17

17 Aug '17

#11785: Kinds should be treated like types in TcSplice -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Template | Version: 8.1 Haskell | 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: -------------------------------------+------------------------------------- !TcSplice handles kinds differently than types. Now that they are the same, it's probably best to rewrite this code. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11785> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #13972: GHC 8.2 error message around indexes for associated type instances is baffling
by GHC 17 Aug '17

17 Aug '17

#13972: GHC 8.2 error message around indexes for associated type instances is baffling -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc2 (Type checker) | Keywords: TypeFamilies, | Operating System: Unknown/Multiple TypeInType | Architecture: | Type of failure: Poor/confusing Unknown/Multiple | error message Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This program doesn't typecheck (only in GHC 8.2 and later): {{{#!hs {-# LANGUAGE PolyKinds #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} module Bug where import Data.Kind class C (a :: k) where type T k :: Type instance C Left where type T (a -> Either a b) = Int }}} {{{ $ /opt/ghc/8.2.1/bin/ghci Bug.hs GHCi, version 8.2.0.20170704: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:12:8: error: • Type indexes must match class instance head Expected: T (a -> Either a b) Actual: T (a -> Either a b) • In the type instance declaration for ‘T’ In the instance declaration for ‘C Left’ | 12 | type T (a -> Either a b) = Int | ^^^^^^^^^^^^^^^^^^^^^^^^^ }}} Well those expected and actual types look pretty darn similar to me! Note that the problem can be worked around by giving an explicit kind annotation for `Left`: {{{#!hs {-# LANGUAGE PolyKinds #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} module Bug where import Data.Kind class C (a :: k) where type T k :: Type instance C (Left :: a -> Either a b) where type T (a -> Either a b) = Int }}} I see two things we could do here: 1. Relax the "Type indexes must match class instance head" check so that it doesn't apply to invisible kind variables like `a` and `b`. 2. Clarify the error message. At the very least, we could say `Expected: T (a1 -> Either a1 b1)` as a hint that `a` and `b` aren't the same type variables as `a1` and `b1`. In an ideal world, we'd even indicate where `a1` and `b1` should be coming from (the kind of `Left`). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13972> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #12087: Inconsistency in GADTs?
by GHC 17 Aug '17

17 Aug '17

#12087: Inconsistency in GADTs? -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: GADTs | 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 f :: Ord a => Eq a => a -> Bool f = … }}} this is allowed but not in GADTs {{{#!hs data F a where MkF :: Ord a => Eq a => a -> F a -- <interactive>:48:16: error: -- • Data constructor ‘MkF’ returns type ‘Eq a => a -> F a’ -- instead of an instance of its parent type ‘F a’ -- • In the definition of data constructor ‘MkF’ -- In the data type declaration for ‘F’ }}} not a big deal -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12087> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #14134: Implement enums for Cmm
by GHC 17 Aug '17

17 Aug '17

#14134: Implement enums for Cmm -------------------------------------+------------------------------------- Reporter: niteria | Owner: (none) Type: feature | Status: new request | Priority: low | Milestone: Component: Compiler | Version: (CodeGen) | 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: -------------------------------------+------------------------------------- Using ANSI C enums is documented as a preferred way of defining constants: https://ghc.haskell.org/trac/ghc/wiki/Commentary/Rts/Conventions#Syntacticd… Basically instead of writing: {{{ #define INVALID_OBJECT 0 #define CONSTR 1 }}} you would write: {{{ typedef enum { INVALID_OBJECT = 0, CONSTR = 1 } ClosureType; }}} What you get is easier debugging in gdb, perhaps even better type checking. Unfortunately some files (most vexingly `rts/storage/ClosureTypes.h`) are included in both C and Cmm and Cmm doesn't support this syntax. As far as I can tell all constants in Cmm are defined with preprocessor `#define`s. Implementing enums/constants may seem like an overkill, but I haven't found a good workaround for this. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14134> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0