- ghc-tickets - Haskell.org

[GHC] #9091: print and/or apply constraints when showing info for typed holes
by GHC 05 Dec '18

05 Dec '18

#9091: print and/or apply constraints when showing info for typed holes -------------------------------------------+------------------------------- Reporter: kosmikus | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: -------------------------------------------+------------------------------- Typed holes are fantastic already, but could be even better. Consider the following three examples: == Example 1 == {{{ f :: Eq a => a -> a -> Bool f x y = _ }}} GHC-7.8.2 shows: {{{ Found hole ‘_’ with type: Bool Relevant bindings include y :: a (bound at THC.hs:4:5) x :: a (bound at THC.hs:4:3) f :: a -> a -> Bool (bound at THC.hs:4:1) In the expression: _ In an equation for ‘f’: f x y = _ }}} GHC additionally knows that `Eq a` holds. It would be great if it would print that, too. == Example 2 == {{{ g :: (forall a. Eq a => a -> Bool) -> Bool g f = f _ }}} GHC-7.8.2 shows: {{{ Found hole ‘_’ with type: a0 Where: ‘a0’ is an ambiguous type variable Relevant bindings include f :: forall a. Eq a => a -> Bool (bound at THC.hs:7:3) g :: (forall a. Eq a => a -> Bool) -> Bool (bound at THC.hs:7:1) In the first argument of ‘f’, namely ‘_’ In the expression: f _ In an equation for ‘g’: g f = f _ }}} GHC additionally knows the `Eq a0` must hold. It would be nice if it could indicate that. == Example 3 == {{{ data X a where Y :: X Int h :: X a -> a -> a h Y x = _ }}} GHC-7.8.2 shows: {{{ Found hole ‘_’ with type: Int Relevant bindings include x :: a (bound at THC.hs:13:5) h :: X a -> a -> a (bound at THC.hs:13:1) In the expression: _ In an equation for ‘h’: h Y x = _ }}} Interestingly, GHC shows that we have to produce an `Int`. Unfortunately, it shows that `x` is of type `a`. GHC additionally knows that `a ~ Int`. It would be nice if GHC could either apply the constraint to show that `x :: Int` or at least show the constraint. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9091> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #15942: Type family used invisibly (with Visible Kind Applications)
by GHC 05 Dec '18

05 Dec '18

#15942: Type family used invisibly (with Visible Kind Applications) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.2 Keywords: | Operating System: Unknown/Multiple TypeApplications | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I want to run the following past you (using [https://phabricator.haskell.org/D5229 Visible Kind Applications] but may be unrelated). The following compiles {{{#!hs {-# Language DataKinds #-} {-# Language KindSignatures #-} {-# Language TypeFamilies #-} {-# Language AllowAmbiguousTypes #-} import Data.Kind type Cat ob = Bool -> Type data Fun :: Cat Type class F (bool :: Bool) where type Not bool :: Bool foo :: Fun (Not bool) }}} but quantifying `Bool` invisibly all of a sudden I can't use `Not` {{{#!hs {-# Language DataKinds #-} {-# Language RankNTypes #-} {-# Language TypeApplications #-} {-# Language PolyKinds #-} {-# Language KindSignatures #-} {-# Language TypeFamilies #-} {-# Language AllowAmbiguousTypes #-} import Data.Kind type Cat ob = forall (b :: Bool). Type data Fun :: Cat Type class F (bool :: Bool) where type Not bool :: Bool foo :: Fun @(Not bool) }}} {{{ $ ghc-stage2 --interactive -ignore-dot-ghci 739_bug.hs GHCi, version 8.7.20181017: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( 739_bug.hs, interpreted ) 739_bug.hs:17:16: error: • Type constructor ‘Not’ cannot be used here (it is defined and used in the same recursive group) • In the first argument of ‘Fun’, namely ‘(Not bool)’ In the type signature: foo :: Fun @(Not bool) In the class declaration for ‘F’ | 17 | foo :: Fun @(Not bool) | ^^^ Failed, no modules loaded. }}} Is this restriction warranted -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15942> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #15997: EventManager could benefit from Data.Primitive.UnliftedArray
by GHC 05 Dec '18

05 Dec '18

#15997: EventManager could benefit from Data.Primitive.UnliftedArray -------------------------------------+------------------------------------- Reporter: chessai | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.3 Component: | Version: 8.6.2 libraries/base | 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 -- | The event manager state. data EventManager = EventManager { emBackend :: !Backend , emFds :: {-# UNPACK #-} !(Array Int (MVar (IntTable [FdData]))) , emState :: {-# UNPACK #-} !(IORef State) , emUniqueSource :: {-# UNPACK #-} !UniqueSource , emControl :: {-# UNPACK #-} !Control , emLock :: {-# UNPACK #-} !(MVar ()) } }}} the field in question is an `Array Int (MVar (IntTable [FdData]))`. `EventManager` could instead be: {{{#!hs type MVarIO = MVar# RealWorld -- type synonym for brevity -- | The event manager state. data EventManager = EventManager { emBackend :: !Backend , emFds :: {-# UNPACK #-} !(UnliftedArray (MVarIO (IntTable [FdData]))) , emState :: {-# UNPACK #-} !(IORef State) , emUniqueSource :: {-# UNPACK #-} !UniqueSource , emControl :: {-# UNPACK #-} !Control , emLock :: {-# UNPACK #-} !(MVar ()) } }}} now the `UnliftedArray` contains non-thunks. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15997> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13480: GHCi display visible type application
by GHC 05 Dec '18

05 Dec '18

#13480: GHCi display visible type application -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #8751 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Similar to #8751, have a way to get GHCi to dump which types an expression is applied to: {{{ ghci> :tyapp length [1,2,3] length @[] @Integer [1,2,3] }}} It could also function as the [https://downloads.haskell.org/~ghc/master /users-guide/ghci.html#ghci-cmd-:all-types :all-types], [https://downloads.haskell.org/~ghc/master/users-guide/ghci.html#ghci-cmd -:type-at :type-at] commands where we can specify a region of code (from [https://www.researchgate.net/publication /282487445_Combining_Deep_and_Shallow_Embedding_of_Domain- Specific_Languages?ev=pubitem-pub_cit_inc Combining Deep and Shallow Embedding of Domain-Specific Languages]) {{{#!hs fromFunC :: FunC (m (Internal a)) -> Mon m a fromFunC m = M $ \k -> fromFunC Bind m k }}} displays {{{#!hs fromFunC :: FunC (m (Internal a)) -> Mon m a fromFunC m = M @m @a $ \(k :: a -> FunC (m b)) -> fromFunC @(FunC (m (Internal a)) -> (a -> FunC (m b)) -> FunC (m b)) (Bind @m @(Internal a) @b) m k }}} Would be great to get this feature as an IDE support. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13480> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #15762: ghci command: report function's inferred visible type applications
by GHC 05 Dec '18

05 Dec '18

#15762: ghci command: report function's inferred visible type applications -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: GHCi | Version: 8.6.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #15610 #15613 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Example inspired by #40. ghci already has a [https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/ghci.html #ghci-cmd-:type-at :type-at] command for reporting a type in a range {{{ >> :type-at X.hs 6 6 6 7 f Int -> Int }}} A similar thing (for integrating into IDEs) is doing the same for visible type applications. An innocent expression like `x y` has a lot going on under the surface {{{#!hs {-# Language RankNTypes #-} {-# Language PolyKinds #-} {-# Language KindSignatures #-} import Data.Kind f :: forall res . (forall k (f :: k -> Type) (a :: k). f a -> res) -> (forall (f :: Type -> Type) . f res) -> res f x y = x y }}} How hard would it be to expand that to `(x @Type @f @res) (y @f)` or (x @Type @Any @res) (y @Any) {{{#!hs f :: forall res (f :: Type -> Type) . (forall k (f :: k -> Type) (a :: k). f a -> res) -> (forall (f :: Type -> Type) . f res) -> res f x y = (x @Type @f @res) (y @f) }}} ---- Other ghci ideas: #15610, #15613 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15762> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #13064: Incorrect redudant imports warning
by GHC 05 Dec '18

05 Dec '18

#13064: Incorrect redudant imports warning -------------------------------------+------------------------------------- Reporter: phadej | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | error/warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- With a simple package: issue.cabal: {{{ name: issue version: 0 cabal-version: >= 1.10 build-type: Simple library build-depends: base, binary, binary-orphans==0.1.5.2 exposed-modules: Issue }}} Issue.hs: {{{ {-# LANGUAGE DeriveGeneric #-} {-# OPTIONS_GHC -Wall #-} module Issue (T (..)) where import Prelude () import Data.Binary.Orphans import Data.Binary (Binary (..)) import GHC.Generics (Generic) import Data.Aeson (Value) data T = T Value deriving (Generic) instance Binary T }}} GHC 7.10.3 correctly reports: {{{ Issue.hs:7:1: Warning: The import of ‘Data.Binary’ is redundant except perhaps to import instances from ‘Data.Binary’ To import instances alone, use: import Data.Binary() }}} GHC 8.0.1 incorrectly (!!!) reports: {{{ Issue.hs:6:1: warning: [-Wunused-imports] The import of ‘Data.Binary.Orphans’ is redundant except perhaps to import instances from ‘Data.Binary.Orphans’ To import instances alone, use: import Data.Binary.Orphans( }}} but `Binary Value` instance is imported from `Data.Binary.Orphans`. --- In real life while compiling https://github.com/futurice/haskell-mega- repo/blob/93c3f111f39c973769c35725d90c9b8ef9a57de3/futurice- github/src/Futurice/GitHub.hs the `Data.Binary` redundant import isn't reported, as `Futurice.Prelude` exports other stuff, which is used. See https://gist.github.com/phadej/bb26df19c611260ab8f867729def39b9 for minimal imports reported with `-ddump-minimal-imports`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13064> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 51

[GHC] #15994: Duplicate entries in -ddump-minimal-imports
by GHC 05 Dec '18

05 Dec '18

#15994: Duplicate entries in -ddump-minimal-imports -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.6.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: -------------------------------------+------------------------------------- Consider {{{ module Foo where import System.IO f = [ReadMode, ReadMode] }}} We get this: {{{ $ ghc -c -ddump-minimal-imports Foo.hs $ cat Foo.imports import System.IO ( IOMode(ReadMode, ReadMode) ) }}} Notice that `ReadMode` appears twice. Turns out this is because of a refactoring in `RnNames` {{{ commit 6353efc7694ba8ec86c091918e02595662169ae2 Author: David Eichmann <EichmannD(a)gmail.com> Date: Thu Nov 22 14:48:05 2018 -0500 Fix unused-import warnings This patch fixes a fairly long-standing bug (dating back to 2015) in RdrName.bestImport, namely }}} (which I wrote -- don't blame David!). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15994> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #15993: Bitwise-oriented semigroup and monoid newtype wrappers for Data.Bits.Bits instances
by GHC 04 Dec '18

04 Dec '18

#15993: Bitwise-oriented semigroup and monoid newtype wrappers for Data.Bits.Bits instances -------------------------------------+------------------------------------- Reporter: koz_ | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.3 Component: | Version: 8.6.2 libraries/base | 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've found myself needing these often, and given the existence of similar newtypes for directing `(<>)` and `mempty` for a range of other types, these are conspicuous by their absence. Additionally, while `oneBits` isn't technically necessary, it's a lot more concise than `complement zeroBits`, and I found myself needing it often. To that end, I've sketched up this implementation. Technically speaking, GND isn't needed, but it means I don't have to repeat myself a lot. These could be made even more concise with `coerce`, but I decided not to do that, since that would require `TypeApplications`. I've limited derivation to methods that are specifically about bitwise operations, rather than stuff like `Num`. {{{#!hs {-# LANGUAGE GeneralizedNewtypeDeriving #-} module Data.Bits.Extra where import Data.Bits ( Bits(..) , FiniteBits(..) ) -- | Monoid under bitwise AND. newtype Conj a = Conj { getConj :: a } deriving (Eq, Bounded, Enum, Bits, FiniteBits) instance (Bits a) => Semigroup (Conj a) where (Conj x) <> (Conj y) = Conj (x .&. y) instance (Bits a) => Monoid (Conj a) where mempty = Conj . complement $ zeroBits -- | Monoid under bitwise OR. newtype Disj a = Disj { getDisj :: a } deriving (Eq, Bounded, Enum, Bits, FiniteBits) instance (Bits a) => Semigroup (Disj a) where (Disj x) <> (Disj y) = Disj (x .|. y) instance (Bits a) => Monoid (Disj a) where mempty = Disj zeroBits -- | Semigroup under bitwise XOR. newtype Xor a = Xor { getXor :: a } deriving (Eq, Bounded, Enum, Bits, FiniteBits) instance (Bits a) => Semigroup (Xor a) where (Xor x) <> (Xor y) = Xor (x `xor` y) -- | Semigroup under bitwise \'equality\'; defined as '1' if the corresponding -- bits match, '0' otherwise. newtype Iff a = Iff { getIff :: a } deriving (Eq, Bounded, Enum, Bits, FiniteBits) instance (Bits a) => Semigroup (Iff a) where (Iff x) <> (Iff y) = Iff . complement $ (x `xor` y) -- not strictly necessary, but would be a big help -- probably should be INLINE oneBits :: (Bits a) => a oneBits = complement zeroBits }}} Potentially this could include more, such as instances of `Ord` based on lexicographic ordering on the bits, rather than defaulting to the underlying one (such as the one for `Int`, which I believe is numeric). However, that's a separate issue. I also don't know if these belong in `Data.Bits` or `Data.Semigroup` (or `Data.Monoid` I guess). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15993> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9221: (super!) linear slowdown of parallel builds on 40 core machine
by GHC 04 Dec '18

04 Dec '18

#9221: (super!) linear slowdown of parallel builds on 40 core machine -------------------------+------------------------------------------------- Reporter: | Owner: carter | Status: new Type: bug | Milestone: Priority: high | Version: 7.8.2 Component: | Operating System: Unknown/Multiple Compiler | Type of failure: Compile-time performance bug Keywords: | Test Case: Architecture: | Blocking: Unknown/Multiple | Difficulty: | Unknown | Blocked By: | Related Tickets: | -------------------------+------------------------------------------------- im seeing slowdowns in parallel builds of a (simple!!) 6 module project when I build it on a 40 core server i'm using for work. for any given ghc invocation with -jn, once n>10, i start to see a super linear slow down as a function of n heres some basic numbers at -j1 0m2.693s at -j4 0m2.507s at -j10 0m2.763s at -j25 0m12.634s at -j30 : 0m39.154s at -j40 : 0m57.511s at -j60 : 2m21.821s these timings are another 2-4x worse if ghc is invoked indirectly via cabal-install / setup.hs according to the linux utility latencytop, 100% of ghc's cpu time was spent on user-space lock contention when I did the -j40 invocation. the timing in the -j40 case stayed the same even when ghc was also passed -O0 (and -fforce-recomp to ensure it did the same ) a bit of experimentation makes me believe that in *ANY* cabalized project on a 40 core machine will exhibit this perf issue. cabal clean ; cabal configure --ghc-options="-j" ; cabal build -j1 should be enough to trigger the lock contention. That said, I'll try to cook up a minimal repro that i can share the source for post haste. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9221> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 90

[GHC] #15937: CI strategy for Gitlab
by GHC 04 Dec '18

04 Dec '18

#15937: CI strategy for Gitlab -------------------------------------+------------------------------------- Reporter: alpmestan | Owner: bgamari Type: task | Status: new Priority: normal | Milestone: Component: Continuous | Version: Integration | 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 have been working on the configuration of the staging gitlab instance recently. We managed to hook it up with both Circle CI and Appveyor, for the `ghc/ghc` (''username/repo'') project on our instance. It all works. Things get tricky when it comes to running CI jobs for forks, though. Indeed, our Circle CI script relies on some CI env vars being defined in the CI settings of the project. Those are "secrets" (e.g circle ci API token) that we do not want to make public and encourage everyone to use, which means that CI simply won't work for forks, out of the box, with things as they stand. Ben and I have discussed this a bit and we see 3 different ways to go about this. 1) Forget about the fork-based workflow. We might consider having a reference repo where things get merged and a "sandbox" repo where people could push their branches and get some CI running. They could then create MRs against the "real" repo to get patches merged. This one way or another requires adding new contributors manually to the "sandbox repo". It is quite likely that they could also get "our secrets" by simply tweaking `.gitlab-ci.yml` to print the right env vars, in their branch. 2) We go for a "full gitlab CI" solution, which might require less work than it initially seems as it could use the same docker images and run roughly the same commands as Circle CI. That requires computational resources though, and makes the transition less smooth. We can certainly consider doing some ''additional'' CI with this, if we make the move definitive and end up refining our CI needs, but we definitely don't want to get rid of Circle CI/Appveyor now anyway. 3) We implement a "mediator" service that would have all our secrets and would get hit by gitlab CI jobs to launch builds and report the results & artifacts. It could therefore behave the same regardless of the user/repo/branch that triggers it without exposing anything. This could be put together somewhat quickly but requires enough work that we may not be able to set that up in time for the initial move. It is however the best solution from the user experience (ghc contributor) point of view. People with developer access to the main repo could push there, or in their forks. Others would only push to their forks and create MRs. CI would work the same in all those cases. In my opinion, going with 1) initially and then 3) as soon as possible is the best plan in the long term. It would make for a great contributor experience while requiring very little maintenance. This could also very easily live side by side with some "real" gitlab CI, that doesn't offload the work to an external service. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15937> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5