December 2018 - ghc-tickets

[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

[GHC] #15992: Alternative instance for Data.Functor.Compose causes <<loop>>s with some types
by GHC 04 Dec '18

04 Dec '18

#15992: Alternative instance for Data.Functor.Compose causes <<loop>>s with some types -------------------------------------+------------------------------------- Reporter: glaebhoerl | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: | Version: 8.6.2 libraries/base | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime crash Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- `many` and `some` are [http://hackage.haskell.org/package/base-4.12.0.0/docs/src/Data.Functor.Comp… omitted] and are filled in by their defaults from `Alternative`, instead of re-using the definitions provided for `f`; this manifests as infinite grammars being created in the case of the Earley parsing library, resulting in `<<loop>>` errors at runtime. The fix is just to add: {{{#!hs many = Compose . fmap sequenceA . many . getCompose some = Compose . fmap sequenceA . some . getCompose }}} Related twitter thread: https://twitter.com/ollfredo/status/1067498140100628480 (It seems like this bug has been around for some time: https://github.com/feuerbach/regex-applicative/issues/19) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15992> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #15460: Literals overflow
by GHC 04 Dec '18

04 Dec '18

#15460: Literals overflow -------------------------------------+------------------------------------- Reporter: hsyl20 | 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: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider the following example: {{{#!hs {-# LANGUAGE MagicHash #-} import GHC.Int main :: IO () main = do let x = I# (0xfffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff#) print x }}} It gets desugared into: {{{#!hs main = print @ Int GHC.Show.$fShowInt (GHC.Types.I# 7237005577332262213973186563042994240829374041602535252466099000494570602495#) }}} Problem: the literal value isn't rounded and there is no overflow warning. It breaks the invariant that literal values in Core have to be in range. Bad things can happen when we break this invariant: {{{#!hs {-# LANGUAGE MagicHash #-} import GHC.Int import Control.Monad main :: IO () main = do let x = I# (0xfffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff#) when (x > maxBound) $ do print "Oups" > ghc TestLitOverflow.hs -Wall -O2 > ./TestLitOverflow "Oups" }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15460> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #15529: runtime bug when profiling retainers
by GHC 04 Dec '18

04 Dec '18

#15529: runtime bug when profiling retainers -------------------------------------+------------------------------------- Reporter: flip101 | 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: -------------------------------------+------------------------------------- I have this project https://github.com/flip111/ghc-runtime-bug1 When i execute the following commands: {{{ stack clean stack build stack build --ghc-options '-j4 -O0 -rtsopts=all -fprof-auto -fprof-auto- calls -fprof-cafs' --executable-profiling stack exec vfix -- +RTS -hr -sstderr }}} After the compilation messages i get the following error: {{{ vfix: internal error: Invalid object *c in pop() (GHC version 8.4.3 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Command terminated by signal 6 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15529> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 21

Re: [GHC] #5793: make nofib awesome
by GHC 04 Dec '18

04 Dec '18

#5793: make nofib awesome -------------------------------------+------------------------------------- Reporter: dterei | Owner: michalt Type: task | Status: new Priority: normal | Milestone: ⊥ Component: NoFib benchmark | Version: suite | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 9571 | Blocking: Related Tickets: #15357 #15333 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by sgraf): Replying to [comment:16 simonmar]: > The rationale for the naming is described in Will's paper [http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.53.4124] The distinction between `spectral` and `imaginary` is mainly size: the `imaginary` programs are microbenchmarks, whereas `spectral` programs are algorithmic kernels - larger than microbenchmarks but not real programs. I think it's a useful distinction. > > Perhaps we also want another distinction - programs that run for long enough that we can obtain reliable timing results. However that's an orthogonal dimension, and we can't sensibly use both dimensions for organising the directory structure. So I suggest we just have a flag per benchmark that is true if it runs for long enough, and have a simple way to run just those benchmarks. > I think flagging offending benchmarks is the last resort to get reliable measurements, but sadly I don't see any way around that for ''some'' benchmarks. Let me elaborate. I experienced fluctuations (random improvements and regressions) for benchmarks with either of the following traits: 1. Runtime too short, so that we mostly measure system overhead (partly addressed by Phab:D4989, in response to #15357) 2. Programs like `paraffins`, `binary-trees`, etc., which consist of a relatively long and allocation intensive build-up phase, followed by a fold that immediately collapses the maximum residency. These kind of benchmarks are very sensitive to changes in allocations. Also see #15333. 3. Microbenchmarks like the `real/eff` suite, which optimise to a very small counting loop. Even when they run long enough for runtime measurements to be reproducible (e.g. `VSM` runs for about 670ms-700ms on my machine), a mostly irrelevant change in `base` leads to wibbles. = System overhead = Easy to fix and Phab:D4989 did most (if not all?) of the work. = GC = The GC parameterisation is much harder to remove from the equation. There's an example in #15333 and https://ghc.haskell.org/trac/ghc/ticket/9476#comment:55 ff. The idea is the following: Varying allocations leads to different points in time at which nursery and gen 2 heap run out of space, in turn triggering GC at different points in time. I.e. imagine that because of an overall reduction in allocations, the 5th major GC run happens ''immediately before'' the entire structure is collapsed, when without the reduction the 5th run would happen some time earlier (left baseline, right less total allocations): [[Image(https://i.imgur.com/C5224Ua.jpg, 300px)]] [[Image(https://i.imgur.com/C05SC5K.jpg, 300px)]] The residency at the 5th GC run would approach the maximum residency (not the number sampled by GC, but the one depending on program semantics), which entails a maximally costly GC run, for an impact of as much as 10% on total runtime. This is something that could be tuned by profile-guided optimisation, but otherwise there is no way to predict when a program will hit its maximum residency. The above profile is from `paraffins`, which has the typical structure of an allocating Haskell benchmark: Build up and then consume a large data structure. Although total allocations can be measured realiably on them, these benchmarks aren't particularly indicative of runtime performance and contribute to nofib's noise. I can think of ways to fix the situation without flagging them away, but not without leaving the respective benchmarks untouched: 1. Modify every benchmark in a way that at least one collection will happen at the point where we think maximum residency is hit, through `performMajorGC` or some other kind of allocation in a loop. Yuck. 2. Iterate every benchmark $n times from within the same Haskell process. In particular, this won't reset the GC between runs and will lead to better distribution of heap samples without actually changing the characteristics of the benchmark. We could shrink input problems to get $n sufficiently high, while still running in acceptable time (e.g. 0.5-5s). TODO Identify them = Microbenchmarks = I blame non-determinism in code layout or some other caching effect until I have a better hypothesis. These are the candidats we want to flag away for runtime measurements, especially `real/eff`, or make them actually do something meaningful. TODO: Identify them -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5793#comment:38> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0