October 2018 - ghc-tickets

[GHC] #15758: hsc2hs broken due to incorrect argument passing to the hsc2hs executable
by GHC 29 Oct '18

29 Oct '18

#15758: hsc2hs broken due to incorrect argument passing to the hsc2hs executable -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 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 packages with .hsc files can't be built with GHC HEAD on some systems becuase of a problem in hsc2hs wrapper script. I don't understand the problem good enough, but we did some debugging with hvr today and he asked me to file a ticket. Here's how to reproduce: {{{ regex-posix-0.95.2 $ cabal new-build --with- ghc=/home/omer/haskell/ghc/inplace/bin/ghc-stage2 Warning: Unknown/unsupported 'ghc' version detected (Cabal 2.4.0.1 supports 'ghc' version < 8.7): /home/omer/haskell/ghc/inplace/bin/ghc-stage2 is version 8.7.20181017 Warning: The package list for 'hackage.haskell.org' is 22 days old. Run 'cabal update' to get the latest list of available packages. Resolving dependencies... Build profile: -w ghc-8.7.20181017 -O1 In order, the following will be built (use -v for more details): - regex-posix-0.95.2 (lib:regex-posix) (first run) Warning: regex-posix.cabal:6:1: The field "build-type" is specified more than once at positions 6:1, 19:1 Configuring regex-posix-0.95.2... Preprocessing library for regex-posix-0.95.2.. hsc2hs: @/home/omer/haskell/regex-posix-0.95.2/dist- newstyle/build/x86_64-linux/ghc-8.7.20181017/regex- posix-0.95.2/build/Text/Regex/Posix/hsc2hs-response17101-2.txt: openBinaryFile: does not exist (No such file or directory) }}} As far as I understand, the problem is that the script runs `hsc2hs -- @foo` instead of `hsc2hs @foo`. Hopefully hvr will correct if I misunderstood. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15758> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #15154: Segmentation fault of ghc-pkg.exe from 32-bit distribution of ghc-8.2.2 on Windows 7
by GHC 29 Oct '18

29 Oct '18

#15154: Segmentation fault of ghc-pkg.exe from 32-bit distribution of ghc-8.2.2 on Windows 7 -------------------------------------+------------------------------------- Reporter: ki11men0w | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: ghc-pkg | Version: 8.2.2 Keywords: | Operating System: Windows Architecture: x86 | Type of failure: Compile-time | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- On `Windows 7` call of `ghc-pkg` utility from `32-bit` `ghc-8.2.2` distribution is always ended with `Segmentation fault` error. With use of `Cygwin` the error can be reproduced this way: run `cmd.exe` and in the appeared console window execute the following commands {{{#!bash c:\Users\user.name\wrk> bash $ mkdir ghc-pkg-check $ cd ghc-pkg-check $ curl https://downloads.haskell.org/~ghc/8.2.2/ghc-8.2.2-i386-unknown- mingw32.tar.xz > ghc-8.2.2-i386-unknown-mingw32.tar.xz % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 163M 100 163M 0 0 3669k 0 0:00:45 0:00:45 --:--:-- 4776k $ xz -dc ghc-8.2.2-i386-unknown-mingw32.tar.xz | tar -xf - $ cd ghc-8.2.2/bin/ $ ./ghc-pkg.exe --version GHC package manager version 8.2.2 Segmentation fault }}} The error arises irrespective of how and with what arguments to call `ghc- pkg` utility. For example, firstly I has faced the problem using `stack` from Windows console: {{{#!bat > stack build --arch=i386 --resolver=11.9 }}} I checked another distributions of GHC for presence of this bug on `Windows 7`. 64-bit version of ghc-8.2.2, 32-bit and 64-bit versions of ghc-8.0.2 and ghc-8.4.2 are free of the problem. I **did not check** the problem **on another versions** of MS Windows. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15154> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #15743: Nail down the Required/Inferred/Specified story
by GHC 28 Oct '18

28 Oct '18

#15743: Nail down the Required/Inferred/Specified story -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- In a class/data/type declaration we need to say precisely which type variables are Inferred/Specified/Required and, for the specified ones, which order they occur in. See `Note [VarBndrs, TyCoVarBinders, TyConBinders, and visibility]` in `TyCoRep`. Reminder: * Required: explicitly-specified arguments to the type constructor, always appear in any user-written type. * Specified: variables mentioned lexically in the declaration, but not positionally. Available for visible kind application. * Inferred: completely invisible in the declaration; always implicit and not available for visible kind application. The rules for top-level (non-associated) declarations. Running example: {{{ data T (b :: (k2 :: k)) c (a :: k) }}} * Categorisation * Required: the positional arguments in the header (`a`, `b`, `c`) * Specified: all the variables mentioned in the declaration header, that are not Required (`k`, `k2`) * Inferred: all the others (the kind of `c`) * Order. We need to specify the order in which the Specfied variables are quantified. Here is the spec: * Specified variables are always quantified before Required ones. (We could revisit this.) * List the specified variables in the textual order in which they appear [`k2`, `k`] * Sort them into dependency order using ''ScopedSort'' (see below), giving [`k`, `k2`] * Finally quantify Inferred, then Specified, then Required. In the example we get {{{ T :: forall {k1}. forall k k2. k2 -> k1 -> k -> Type }}} The ''ScopedSort'' algorithm works as follows * Do dependency analysis, so for each variable we know what other variables it depends on, transitively. By "depends on" we mean after full kind inference, not just what is written in the source program. * Work left-to-right through the list, with a cursor. * If variable `v` at the cursor is depended on by any earlier variable `w`, move `v` immediately before the leftmost such `w`. The invariant is that the variables to the left of the cursor form a valid telescope. For associated types, use this running example: {{{ class C (a :: k) where type T a (b :: k2) }}} The rules are elaborated a bit for an associated type like `T` * Required: the explicit positional arguments (here `a`, `b`) * Specified: any non-Required variable that is * mentioned (lexically) in the class header and transitively depended on by the Required variables (here `k`), listed left-to-right; followed by * any other variables mentioned in the type header (here `k2`), again listed left-right. * Inferred: all the others, as before. The Specified variables are sorted exactly as before. Relevant tickets * #14887 esp comment:10 (order of Inferred type variables) * #15592 * #15591 comment:4ff (All following discussion with RAE Friday 12 Oct.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15743> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15

[GHC] #14552: GHC panic on pattern synonym
by GHC 28 Oct '18

28 Oct '18

#14552: GHC panic on pattern synonym -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Keywords: | Operating System: Unknown/Multiple PatternSynonyms, TypeInType, | ViewPatterns | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs {-# Language RankNTypes, ViewPatterns, PatternSynonyms, TypeOperators, KindSignatures, PolyKinds, DataKinds, TypeFamilies, TypeInType, GADTs #-} import Data.Kind data family Sing a type a --> b = (a, b) -> Type type family (@@) (f::a --> b) (x::a) :: b data Proxy a = Proxy newtype Limit' :: (k --> Type) -> Type where Limit' :: (forall xx. Proxy xx -> f@@xx) -> Limit' f data Exp :: [Type] -> Type -> Type where TLam' :: Proxy f -> (forall aa. Proxy aa -> Exp xs (f @@ aa)) -> Exp xs (Limit' f) pattern FOO f <- TLam' Proxy (($ Proxy) -> f) }}} ---> {{{ $ ghci -ignore-dot-ghci 119-bug.hs GHCi, version 8.3.20171122: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( 119-bug.hs, interpreted ) ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.3.20171122 for x86_64-unknown-linux): ASSERT failed! in_scope InScope {a_a1Mh b_a1Mi rep_a1MB r_a1MC} tenv [a1MC :-> r_a1MC] cenv [] tys [k_a1Mj[ssk:3]] cos [] needInScope [a1Mj :-> k_a1Mj[ssk:3]] Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1205:22 in ghc:Outputable assertPprPanic, called at compiler/types/TyCoRep.hs:2136:51 in ghc:TyCoRep checkValidSubst, called at compiler/types/TyCoRep.hs:2159:29 in ghc:TyCoRep substTy, called at compiler/types/TyCoRep.hs:2364:41 in ghc:TyCoRep substTyVarBndr, called at compiler/coreSyn/CoreSubst.hs:571:10 in ghc:CoreSubst Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1147:37 in ghc:Outputable pprPanic, called at compiler/utils/Outputable.hs:1203:5 in ghc:Outputable assertPprPanic, called at compiler/types/TyCoRep.hs:2136:51 in ghc:TyCoRep checkValidSubst, called at compiler/types/TyCoRep.hs:2159:29 in ghc:TyCoRep substTy, called at compiler/types/TyCoRep.hs:2364:41 in ghc:TyCoRep substTyVarBndr, called at compiler/coreSyn/CoreSubst.hs:571:10 in ghc:CoreSubst Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14552> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #15591: Inconsistent kind variable binder visibility between associated and non-associated type families
by GHC 28 Oct '18

28 Oct '18

#15591: Inconsistent kind variable binder visibility between associated and non- associated type families -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Keywords: | Operating System: Unknown/Multiple TypeApplications, TypeFamilies | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider the following program and GHCi session which uses it: {{{#!hs {-# LANGUAGE PolyKinds #-} {-# LANGUAGE TypeFamilies #-} module Foo where import Data.Kind type family T1 (x :: f (a :: Type)) class C (a :: Type) where type T2 (x :: f a) }}} {{{ $ ghc2/inplace/bin/ghc-stage2 --interactive Foo.hs -fprint-explicit- foralls GHCi, version 8.7.20180831: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Foo ( Foo.hs, interpreted ) Ok, one module loaded. λ> :kind T1 T1 :: forall (f :: * -> *) a. f a -> * λ> :kind T2 T2 :: forall {a} (f :: * -> *). f a -> * }}} Something is strange about the visibility of `a` in the kinds of `T1` and `T2`. In `T1`, it's visible, but in `T2`, it's not! I would expect them to both be visible, since they were both mentioned by name in each type family's definition. This isn't of much importance at the moment, but it will be once visible kind application lands, as this bug will prevent anyone from instantiating the `a` in `T2` using a kind application. I indicated 8.5 as the version for this ticket since this behavior has changed since GHC 8.4, where you'd get the following: {{{ $ /opt/ghc/8.4.3/bin/ghci Foo.hs -fprint-explicit-foralls GHCi, version 8.4.3: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Foo ( Foo.hs, interpreted ) Ok, one module loaded. λ> :kind T1 T1 :: forall (f :: * -> *) a. f a -> * λ> :kind T2 T2 :: forall (f :: * -> *) a. f a -> * }}} Here, both `a`s are visible. However, it's still wrong in that `a` should be listed before `f` in `T2`'s telescope, since `a` was bound first (in `C`'s class head), before `f`. In that sense, the current behavior is a slight improvement, although we're not fully correct yet. The only difference between `T1` and `T2` is that `T2` is associated with a class, which suggests that there is some difference in code paths between the two that is accounting for this. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15591> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #15818: Bump template-haskell version to 2.15.0.0
by GHC 28 Oct '18

28 Oct '18

#15818: Bump template-haskell version to 2.15.0.0 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Template | Version: 8.7 Haskell | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #2600, #14268 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Commit 512eeb9bb9a81e915bfab25ca16bc87c62252064 (`More explicit foralls (GHC Proposal 0007)`) introduced breaking changes to the Template Haskell AST. As a consequence of this, there are libraries in the wild that now fail to build on GHC HEAD (for instance, [https://github.com/glguy/th- abstraction/issues/55 th-abstraction]). We should properly bump the `template-haskell` library's version number to `2.15.0.0` so that these libraries can guard against these changes using `MIN_VERSION_template_haskell`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15818> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #15811: Comment out CONSTANT_FOLDED annotation for some GHC.Natural functions
by GHC 28 Oct '18

28 Oct '18

#15811: Comment out CONSTANT_FOLDED annotation for some GHC.Natural functions -------------------------------------+------------------------------------- Reporter: darchon | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): Phab:D5267 | Wiki Page: -------------------------------------+------------------------------------- Some functions in GHC.Natural with a CONSTANT_FOLDED annotation don't have actual builtin rules (nor a builtin name in PrelNames and friends). This is hurting the Clash compiler because the workers for these functions do not end up in the .hi interface files, nor can we reliably define primops; meaning Clash cannot translate functions over Natural. This is doubly problematic because Natural is the underlying representation for KnownNat which Clash uses extensively. This feature request is simply a backstop for GHC 8.6.2 until proper builtin rules have been defined for the functions over the relevant Natural functions. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15811> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #15819: COMPLETE pragma not listed in GHC manual index
by GHC 28 Oct '18

28 Oct '18

#15819: COMPLETE pragma not listed in GHC manual index -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 8.6.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 wanted information on the `COMPLETE` pragma. So I went to GHC's manual's index. And it isn't there! We should likely have some RST gubbins to support pragmas, in much the same way that we do for flags, as I'm sure this isn't only `COMPLETE`'s problem. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15819> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #15824: Prefix/infix distinction in TemplateHaskell types is lost
by GHC 28 Oct '18

28 Oct '18

#15824: Prefix/infix distinction in TemplateHaskell types is lost -------------------------------------+------------------------------------- Reporter: int-index | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 8.6.1 Haskell | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #15815, #15760 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider `data T a b = a :. b`. In the declaration, `:.` is mapped to `InfixC`: {{{ ghci> putStrLn $(reify ''T >>= stringE . show) TyConI (DataD [] T [KindedTV a StarT,KindedTV b StarT] Nothing [InfixC (Bang NoSourceUnpackedness NoSourceStrictness,VarT a) :. (Bang NoSourceUnpackedness NoSourceStrictness,VarT b)] []) }}} In expressions, `a :. b` is mapped to `InfixE`: {{{ ghci> runQ [e| 1 :+ 2 |] >>= print InfixE (Just (LitE (IntegerL 1))) (ConE :+) (Just (LitE (IntegerL 2))) }}} In patterns, `a :. b` is mapped to `InfixP`: {{{ ghci> runQ [p| 1 :. 2 |] >>= print InfixP (LitP (IntegerL 1)) :. (LitP (IntegerL 2)) }}} In types, `a :. b` is mapped to `InfixT`: {{{ ghci> runQ [t| 1 :. 2 |] >>= print InfixT (LitT (NumTyLit 1)) (PromotedT :.) (LitT (NumTyLit 2)) }}} That last one was a lie. In reality, in types `a :. b` is mapped to nested `AppT`: {{{ ghci> runQ [t| 1 :. 2 |] >>= print AppT (AppT (PromotedT :.) (LitT (NumTyLit 1))) (LitT (NumTyLit 2)) }}} This is despite the existence of `InfixT`. The same issue can be observed when reifying types: {{{ ghci> type A = 1 :. 2 ghci> putStrLn $(reify ''A >>= stringE . show) TyConI (TySynD A [] (AppT (AppT (PromotedT :.) (LitT (NumTyLit 1))) (LitT (NumTyLit 2)))) }}} This is not specific to infix constructors and can be observed with any infix (type) operators. It's best to change this in the same release as we fix #15760, as there is code in the wild that is prepared to face neither `InfixT` nor `ParensT`, and it would break silently. RyanGlScott gives an example of such code: [https://github.com/glguy/th- abstraction/blob/5123c6d054d0949cb444590269f13e5d44699ab2/src/Language/Haskell/TH/Datatype.hs#L1156-L1160 decomposeType from th-desugar]. This issue is in part responsible for #15815, see comment:5:ticket:15815. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15824> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #15685: Pattern signature not inferred
by GHC 28 Oct '18

28 Oct '18

#15685: Pattern signature not inferred -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.6.1 Keywords: | Operating System: Unknown/Multiple PatternSynonyms | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Should this pattern synonym declaration fail, {{{#!hs {-# Language DataKinds, TypeOperators, PolyKinds, GADTs, PatternSynonyms #-} import Data.Kind data NS f as where Here :: f a -> NS f (a:as) data NP :: (k -> Type) -> ([k] -> Type) where Nil :: NP f '[] pattern HereNil = Here Nil }}} {{{ $ ghci -ignore-dot-ghci hs/457.hs GHCi, version 8.7.20180828: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( hs/457.hs, interpreted ) [flags changed] hs/457.hs:11:19: error: • Could not deduce: f ~~ NP f0 from the context: (as ~ (a1 : as1), GHC.Types.Any ~ '[]) bound by the signature for pattern synonym ‘HereNil’ at hs/457.hs:11:1-26 ‘f’ is a rigid type variable bound by the signature for pattern synonym ‘HereNil’ at hs/457.hs:11:1-26 Expected type: NS f as Actual type: NS (NP f0) ('[] : as0) • In the expression: Here Nil In an equation for ‘HereNil’: HereNil = Here Nil • Relevant bindings include $bHereNil :: NS f as (bound at hs/457.hs:11:9) | 11 | pattern HereNil = Here Nil | ^^^^^^^^ hs/457.hs:11:24: error: • Kind mismatch: cannot unify (f :: a -> *) with: NP a0 :: [GHC.Types.Any] -> * Their kinds differ. Expected type: f a1 Actual type: NP a0 GHC.Types.Any • In the pattern: Nil In the pattern: Here Nil In the declaration for pattern synonym ‘HereNil’ | 11 | pattern HereNil = Here Nil | ^^^ Failed, no modules loaded. Prelude> }}} It can be given a pattern signature, my question is can this not be inferred {{{#!hs -- pattern HereNil :: NS (NP f) ('[]:as) pattern HereNil :: () => (nil_as ~ ('[]:as)) => NS (NP f) nil_as pattern HereNil = Here Nil }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15685> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7