October 2018 - ghc-tickets

[GHC] #9545: Evaluate Takano Akio's foldrW/buildW fusion framework as a possible replacement for foldr/build
by GHC 29 Oct '18

29 Oct '18

#9545: Evaluate Takano Akio's foldrW/buildW fusion framework as a possible replacement for foldr/build -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: task | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Project (more | Type of failure: than a week) | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Takano Akio's [https://github.com/takano-akio/ww-fusion worker-wrapper fusion] modifies `foldr/build` fairly conservatively to allow safe fusion of `foldl` and friends without relying on arity analysis. This advantage is important for two reasons that I know of: 1. As discussed in Joachim Breitner's original paper, the current arity analysis is unable to infer arity correctly when facing certain forms of recursion. 2. The current arity analysis, and probably ''any'' practical arity analysis, depends on inlining to a degree that can sometimes be unhealthy. I would love to make functions like `hPutStr` fuse, but I suspect doing so safely at present would likely cause a code explosion—the function being folded is too large to want to inline to make it available for arity analysis following fusion. I don't understand it completely yet, but it looks like `foldrW/buildW` can eliminate a lot of this uncertainty. Furthermore, it appears that functions currently written using `foldr` in a "right-handed" way can remain unchanged, using an implementation of `foldr` in terms of `foldrW`. Only "left-handed" folds will need to be rewritten to take advantage of this framework, along with all the `build`s. That said, `foldrW/buildW` probably has its weaknesses too. The basic fusion rule looks like this. {{{#!hs {-# RULES "foldrW/buildW" forall f z (i :: Wrap f b) (g :: forall c g . (Wrap g c) -> (a -> c -> c) -> c -> c) . foldrW i f z (buildW g) = g i f z #-} }}} If `g` and `i` are not inlined sufficiently to merge with each other, I imagine this could produce worse results than `foldr/build` when the latter works properly. The only way to really get a feel for performance would be to carefully modify everything to work as well as it can with this framework and see how the results compare. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9545> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #9374: Investigate Static Argument Transformation
by GHC 29 Oct '18

29 Oct '18

#9374: Investigate Static Argument Transformation -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- At the moment the Static Argument Transformation (SAT) optimisation is not run unless explicitly enabled with `-fstatic-argument-transformation`. The comment in DynFlags says: {{{ Max writes: I think it's probably best not to enable SAT with -O2 for the 6.10 release. The version of SAT in HEAD at the moment doesn't incorporate several improvements to the heuristics, and I'm concerned that without those changes SAT will interfere with some attempts to write "high performance Haskell", as we saw in some posts on Haskell-Cafe earlier this year. In particular, the version in HEAD lacks the tail call criterion, so many things that look like reasonable loops will be turned into functions with extra (unneccesary) thunk creation. }}} 6.10 was a long time ago. Has anything changed since then? Does it make sense to enable that optimisation now? What are the mentioned heuristics and were they finally implemented? Does anyone know what Haskell-cafe posts does Max refer to? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9374> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 30

[GHC] #11719: Cannot use higher-rank kinds with type families
by GHC 29 Oct '18

29 Oct '18

#11719: Cannot use higher-rank kinds with type families -------------------------------------+------------------------------------- Reporter: ocharles | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc2 (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 ticket came out of a discussion with Richard in this mailing list post: https://mail.haskell.org/pipermail/haskell- cafe/2016-March/123462.html Here's the code that should work, but doesn't: {{{ import Data.Kind data TyFun :: * -> * -> * type a ~> b = TyFun a b -> * type family (f :: a ~> b) @@ (x :: a) :: b data Null a = Nullable a | NotNullable a type family ((f :: b ~> c) ∘ (g :: a ~> b)) (x :: a) :: c where (f ∘ g) x = f @@ (g @@ x) type family BaseType (k :: forall a. a ~> Type) (x :: b) :: Type where -- this fails :( -- BaseType k x = (@@) k x }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11719> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 22

[GHC] #15071: :set usage in ghci tests breaks platform independence of output
by GHC 29 Oct '18

29 Oct '18

#15071: :set usage in ghci tests breaks platform independence of output -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Test Suite | Version: 8.2.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: -------------------------------------+------------------------------------- Numerous GHCi tests are currently failing on Windows due to the use of `:set`, which prints the default flag set, which is platform dependent. For instance: {{{ --- "/tmp/ghctest-eo_ri0ye/test spaces/./ghci/scripts/ghci024.run/ghci024.stdout.normalised" 2018-04-19 18:35:50.927278200 +0000 +++ "/tmp/ghctest-eo_ri0ye/test spaces/./ghci/scripts/ghci024.run/ghci024.run.stdout.normalised" 2018-04-19 18:35:50.927278200 +0000 @@ -7,7 +7,6 @@ GHCi-specific dynamic flag settings: other dynamic, non-language, flag settings: -fno-diagnostics-show-caret - -fexternal-dynamic-refs -fignore-optim-changes -fignore-hpc-changes -fno-ghci-history }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15071> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #15830: Plugins Tests are Skipped
by GHC 29 Oct '18

29 Oct '18

#15830: Plugins Tests are Skipped -------------------------------------+------------------------------------- Reporter: davide | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.1 (Hadrian) | Keywords: plugins test | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: plugins01 | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The test driver skips the plugins01 test after building the default flavour with hadrian. testsuite/tests/plugins/all.T specifies `only_ways([config.ghc_plugin_way]`. Some how this condition is not met. Open questions: * Are all plugin* tests skipped? * Are these tests also skipped when built/run via make? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15830> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #15829: Add a test case for tricky type synonyms involving visible dependent kinds
by GHC 29 Oct '18

29 Oct '18

#15829: Add a test case for tricky type synonyms involving visible dependent kinds -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.7 (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 code does not typecheck on GHC 8.6.1: {{{#!hs {-# LANGUAGE DataKinds #-} {-# LANGUAGE PolyKinds #-} module Bug where import Data.Kind data A :: Type -> Type data B a :: A a -> Type type C a = B a }}} However, it //does// typecheck on GHC HEAD, after commit 5e45ad10ffca1ad175b10f6ef3327e1ed8ba25f3 (Finish fix for #14880.). This is very cool, although it does alarm me that there is no test case which checks for this at the moment. Let's add one to ensure that this stays fixed. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15829> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #15825: Core Lint error from Explicit Foralls Proposal
by GHC 29 Oct '18

29 Oct '18

#15825: Core Lint error from Explicit Foralls Proposal -------------------------------------+------------------------------------- Reporter: Iceland_jack | 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: -------------------------------------+------------------------------------- This is using the recent Explicit Foralls Proposal #14268 {{{#!hs {-# Language RankNTypes #-} {-# Language PolyKinds #-} {-# Language KindSignatures #-} {-# Language DataKinds #-} {-# Language FlexibleInstances #-} {-# Options_GHC -dcore-lint #-} type C k = (forall (x::k). *) class X (a :: *) instance forall (a :: C k). X (a :: *) }}} {{{ $ ./inplace/bin/ghc-stage2 --interactive -ignore-dot-ghci /tmp/599_bug.hs GHCi, version 8.7.20181025: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( 599_bug.hs, interpreted ) *** Core Lint errors : in result of Desugar (before optimization) *** <no location info>: warning: In the expression: C:X @ a_a1yJ Kind application error in type ‘a_a1yJ’ Function kind = C k_a1yI Arg kinds = [(x_a1yH, k_a1yG)] Forall: x_a1xE k_a1yI (x_a1yH, k_a1yG) <no location info>: warning: In the expression: C:X @ a_a1xG Kind application error in type ‘a_a1xG’ Function kind = C k_X1xQ Arg kinds = [(x_a1yv, k_a1xF)] Forall: x_a1xE k_X1xQ (x_a1yv, k_a1xF) *** Offending Program *** Rec { $tcX :: TyCon [LclIdX] $tcX = TyCon 6136962148358085538## 2047526523769221729## $trModule (TrNameS "X"#) 0# $krep_a1zH $tc'C:X :: TyCon [LclIdX] $tc'C:X = TyCon 12994509767826319747## 2028070155085790741## $trModule (TrNameS "'C:X"#) 1# $krep_a1zJ $krep_a1zK [InlPrag=NOUSERINLINE[~]] :: KindRep [LclId] $krep_a1zK = $WKindRepVar (I# 0#) $krep_a1zH [InlPrag=NOUSERINLINE[~]] :: KindRep [LclId] $krep_a1zH = KindRepFun krep$* $krep_a1zI $krep_a1zI [InlPrag=NOUSERINLINE[~]] :: KindRep [LclId] $krep_a1zI = KindRepTyConApp $tcConstraint ([] @ KindRep) $krep_a1zJ [InlPrag=NOUSERINLINE[~]] :: KindRep [LclId] $krep_a1zJ = KindRepTyConApp $tcX (: @ KindRep $krep_a1zK ([] @ KindRep)) $trModule :: Module [LclIdX] $trModule = Module (TrNameS "main"#) (TrNameS "Main"#) $fXa [InlPrag=NOUSERINLINE CONLIKE] :: forall k (x :: k) k (a :: C k). X a [LclIdX[DFunId], Unf=DFun: \ (@ k_a1xF) (@ (x_a1yv :: k_a1xF)) (@ k_a1xF) (@ (a_a1xG :: C k_a1xF)) -> C:X TYPE: a_a1xG] $fXa = \ (@ k_a1yG) (@ (x_a1yH :: k_a1yG)) (@ k_a1yI) (@ (a_a1yJ :: C k_a1yI)) -> C:X @ a_a1yJ end Rec } *** End of Offense *** <no location info>: error: Compilation had errors *** Exception: ExitFailure 1 > }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15825> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #15076: Typed hole causes GHC to panic (No skolem info)
by GHC 29 Oct '18

29 Oct '18

#15076: Typed hole causes GHC to panic (No skolem info) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 (Type checker) | Keywords: TypedHoles, | Operating System: Unknown/Multiple TypeInType | Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: #14040 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Spun out from https://ghc.haskell.org/trac/ghc/ticket/14040#comment:2, which was different enough from the original program in #14040 to warrant its own ticket. The following program panics on every version of GHC from 8.0.2 onward: {{{#!hs {-# LANGUAGE RankNTypes #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeInType #-} module Bug where import Data.Kind import Data.Proxy newtype S (f :: k1 -> k2) = MkS (forall t. Proxy t -> Proxy (f t)) foo :: forall (a :: Type) (f :: forall (x :: a). Proxy x -> Type). S f -> () foo (MkS (sF :: _)) = () }}} {{{ $ ~/Software/ghc/inplace/bin/ghc-stage2 --interactive Bug.hs GHCi, version 8.5.20180420: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:15:17: error:ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.5.20180420 for x86_64-unknown-linux): No skolem info: [a1_a1Cb[sk:1]] Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1162:37 in ghc:Outputable pprPanic, called at compiler/typecheck/TcErrors.hs:3224:5 in ghc:TcErrors }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15076> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #15389: -Wall-missed-specialisations warnings not fatal with -Werror
by GHC 29 Oct '18

29 Oct '18

#15389: -Wall-missed-specialisations warnings not fatal with -Werror -------------------------------------+------------------------------------- Reporter: ChaiTRex | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.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: -------------------------------------+------------------------------------- When compiling a program with GHC 8.4.3, vector 0.12.0.1 (with a dependency on primitive 0.6.4.0) and `-Wall-missed-specialisations -Werror`, warnings are produced, but they aren't fatal. `-Werror` should make them fatal but doesn't. A somewhat-minimal example: {{{#!hs {-# OPTIONS_GHC -Wall-missed-specialisations -Werror #-} {-# LANGUAGE MultiParamTypeClasses, TypeFamilies #-} module Warnings3 where import GHC.Base (liftM) import qualified Data.Vector.Generic.Base as G (Vector, basicUnsafeFreeze, basicUnsafeThaw, basicLength, basicUnsafeSlice, basicUnsafeIndexM, basicUnsafeCopy, elemseq) import qualified Data.Vector.Generic.Mutable.Base as GM (MVector, basicLength, basicUnsafeSlice, basicOverlaps, basicUnsafeNew, basicInitialize, basicUnsafeReplicate, basicUnsafeRead, basicUnsafeWrite, basicClear, basicSet, basicUnsafeCopy, basicUnsafeMove, basicUnsafeGrow) import qualified Data.Vector.Unboxed as U (Unbox, Vector) import qualified Data.Vector.Unboxed.Mutable as U (MVector) newtype T = T () deriving (Show, Eq, Ord) newtype C = C (U.Vector T) deriving (Show, Eq, Ord) instance U.Unbox T newtype instance U.MVector s T = MV_T (U.MVector s ()) instance GM.MVector U.MVector T where basicLength (MV_T mv) = GM.basicLength mv basicUnsafeSlice i l (MV_T mv) = MV_T (GM.basicUnsafeSlice i l mv) basicOverlaps (MV_T mv1) (MV_T mv2) = GM.basicOverlaps mv1 mv2 basicUnsafeNew l = MV_T `liftM` GM.basicUnsafeNew l basicInitialize (MV_T mv) = GM.basicInitialize mv basicUnsafeReplicate l _ = MV_T `liftM` GM.basicUnsafeReplicate l () basicUnsafeRead (MV_T mv) i = const (T ()) `liftM` GM.basicUnsafeRead mv i basicUnsafeWrite (MV_T mv) i _ = GM.basicUnsafeWrite mv i () basicClear (MV_T mv) = GM.basicClear mv basicSet (MV_T mv) x = GM.basicSet mv () basicUnsafeCopy (MV_T mv1) (MV_T mv2) = GM.basicUnsafeCopy mv1 mv2 basicUnsafeMove (MV_T mv1) (MV_T mv2) = GM.basicUnsafeMove mv1 mv2 basicUnsafeGrow (MV_T mv) l = MV_T `liftM` GM.basicUnsafeGrow mv l newtype instance U.Vector T = V_T (U.Vector ()) instance G.Vector U.Vector T where basicUnsafeFreeze (MV_T mv) = V_T `liftM` G.basicUnsafeFreeze mv basicUnsafeThaw (V_T v) = MV_T `liftM` G.basicUnsafeThaw v basicLength (V_T v) = G.basicLength v basicUnsafeSlice i l (V_T v) = V_T (G.basicUnsafeSlice i l v) basicUnsafeIndexM (V_T v) i = const (T ()) `liftM` G.basicUnsafeIndexM v i basicUnsafeCopy (MV_T mv) (V_T v) = G.basicUnsafeCopy mv v elemseq (V_T v) _ = G.elemseq v () }}} The warnings are: {{{ src/Warnings3.hs: warning: Could not specialise imported function ‘Data.Vector.Unboxed.$w$cshowsPrec’ when specialising ‘Data.Vector.Unboxed.$fShowVector_$cshowsPrec’ Probable fix: add INLINABLE pragma on ‘Data.Vector.Unboxed.$w$cshowsPrec’ src/Warnings3.hs: warning: Could not specialise imported function ‘Data.Vector.Unboxed.$fOrdVector_$cmin’ Probable fix: add INLINABLE pragma on ‘Data.Vector.Unboxed.$fOrdVector_$cmin’ src/Warnings3.hs: warning: Could not specialise imported function ‘Data.Vector.Unboxed.$fOrdVector_$cmax’ Probable fix: add INLINABLE pragma on ‘Data.Vector.Unboxed.$fOrdVector_$cmax’ }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15389> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #15711: Kind inference of class variables does not examine associated types
by GHC 29 Oct '18

29 Oct '18

#15711: Kind inference of class variables does not examine associated types -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Keywords: TypeInType | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- If I say this {{{ {-# LANGUAGE TypeFamilies, PolyKinds, DataKinds #-} module Bug where class C a where type F (x :: Maybe a) }}} then GHCi says this {{{ *Bug> :k C C :: k -> Constraint }}} That's silly. `C` should have kind `Type -> Constraint`, because the usage of `a` in the kind of the associated type constraints `a`'s kind. Will fix. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15711> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3