- ghc-tickets - Haskell.org

[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

[GHC] #10739: Resuscitate the humble ticky-ticky profiler
by GHC 04 Dec '18

04 Dec '18

#10739: Resuscitate the humble ticky-ticky profiler -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- The [https://ghc.haskell.org/trac/ghc/wiki/Debugging/TickyTicky ticky- ticky profiler] is known to be quite bit-rotted. Indeed there currently isn't even a definitive list of the counters, much less what they counter and whether they are still accurate. That being said, it can be quite useful and is worth putting effort into bringing back up to grade. There are a few things that need to be done here, 1. Collect a list of the existing counters 2. Work out what they are supposed to be measuring 3. Decide which still have a chance of being useful and accurate 4. ??? 5. Profile! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10739> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #15814: Orphan Instance Overlap Error Message
by GHC 04 Dec '18

04 Dec '18

#15814: Orphan Instance Overlap Error Message -------------------------------------+------------------------------------- Reporter: parsonsmatt | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 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'm working on moving some code around which unfortunately relies on orphan instances. This is the error I get: {{{ /home/matt/Projects/cardano-sl/wallet- new/src/Cardano/Wallet/API/V1/Types.hs:1794:27: error: • Overlapping instances for Arbitrary (NonEmpty PaymentDistribution) arising from a use of ‘arbitrary’ Matching instances: instance Arbitrary a => Arbitrary (NonEmpty a) -- Defined in ‘Pos.Util.Example’ instance [safe] Arbitrary a => Arbitrary (NonEmpty a) -- Defined in ‘quickcheck- instances-0.3.18:Test.QuickCheck.Instances.Semigroup’ • In the second argument of ‘(<*>)’, namely ‘arbitrary’ In the first argument of ‘(<*>)’, namely ‘Payment <$> arbitrary <*> arbitrary’ In the first argument of ‘(<*>)’, namely ‘Payment <$> arbitrary <*> arbitrary <*> arbitrary’ | 1794 | <*> arbitrary | ^^^^^^^^^ }}} The first instance is the one that I have defined. The second is defined in library code upstream -- great! I want to use that one instead. However, I don't have a clue which module import is providing that instance. It would be *fantastic* if there was an additional line that says which module imported the instance, or brought it into scope. Multiple modules might do this; in this case, reporting any of them would be fine. Eg: {{{ /home/matt/Projects/cardano-sl/wallet- new/src/Cardano/Wallet/API/V1/Types.hs:1794:27: error: • Overlapping instances for Arbitrary (NonEmpty PaymentDistribution) arising from a use of ‘arbitrary’ Matching instances: instance Arbitrary a => Arbitrary (NonEmpty a) -- Defined in ‘Pos.Util.Example’ -- and imported via | 186 | import Cardano.Wallet.API.V1.Swagger.Example | instance [safe] Arbitrary a => Arbitrary (NonEmpty a) -- Defined in ‘quickcheck- instances-0.3.18:Test.QuickCheck.Instances.Semigroup’ -- and imported via | ??? | this information would literally make my day | • In the second argument of ‘(<*>)’, namely ‘arbitrary’ In the first argument of ‘(<*>)’, namely ‘Payment <$> arbitrary <*> arbitrary’ In the first argument of ‘(<*>)’, namely ‘Payment <$> arbitrary <*> arbitrary <*> arbitrary’ | 1794 | <*> arbitrary | ^^^^^^^^^ }}} I'll have to binary search the import list to try and figure out which module is bringing the instance into scope otherwise. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15814> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #15959: If a type signature is too long to read left-to-right then let it read top-to-bottom.
by GHC 04 Dec '18

04 Dec '18

#15959: If a type signature is too long to read left-to-right then let it read top- to-bottom. -------------------------------------+------------------------------------- Reporter: philderbeast | Owner: (none) Type: feature | Status: new request | 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: -------------------------------------+------------------------------------- When pretty printing a type signature that is too long to show in one line, can we please break the lines on the top-level punctuation of the type signature, on {{{::}}}, {{{=>}}} and {{{->}}} as shown in the second listing below? {{{ FlareTiming/Task/Score.hs:186:1: warning: [-Wmissing-signatures] Top-level binding with no type signature: showMax :: (Reflex t, Functor f) => (a -> b) -> (f b -> b -> c) -> Dynamic t (f a) -> Dynamic t a -> Dynamic t c | 186 | showMax getField f pt points = | ^^^^^^^ }}} {{{ FlareTiming/Task/Score.hs:186:1: warning: [-Wmissing-signatures] Top-level binding with no type signature: showMax :: (Reflex t, Functor f) => (a -> b) -> (f b -> b -> c) -> Dynamic t (f a) -> Dynamic t a -> Dynamic t c | 186 | showMax getField f pt points = | ^^^^^^^ }}} If a type signature is too long to display in one line and read left-to- right then please let it read top-to-bottom. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15959> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #15935: TYPE is not generated by genprimops
by GHC 04 Dec '18

04 Dec '18

#15935: TYPE is not generated by genprimops -------------------------------------+------------------------------------- Reporter: davide | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Core | Version: 8.6.2 Libraries | Keywords: GHC.Magic | Operating System: Unknown/Multiple TYPE haddock GHC.Prim genprimops | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- During validation, GHC.Magic must build without warning, and must also type check with Haddock without warnings. This causes some awkwardness in GHC.Magic (see the comment above the imports regarding genprimops) because TYPE is exported from GHC.Prim and reexported by GHC.Types. We are forced to explicitly import it via GHC.Types (and not from GHC.Prim to avoid an unused import warnings). Importing via GHC.Prim would not type check with Haddock as genprimops doesn't generate TYPE for GHC.Prim. This issue surfaced in patch D5312. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15935> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #15991: Regression in error message when attempting to let bind an existentially quantified type
by GHC 04 Dec '18

04 Dec '18

#15991: Regression in error message when attempting to let bind an existentially quantified type -------------------------------------+------------------------------------- Reporter: mmailhot | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.3 Component: Compiler | Version: 8.4.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Poor/confusing Unknown/Multiple | error message Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When attempting to compile the following (invalid) program: {{{#!hs {-# LANGUAGE ExistentialQuantification #-} data Foo = forall a. Foo a main :: IO () main = let Foo x = Foo 1 in return () }}} GHC 8.6.2.0 (and 8.6.1.0, 8.4.1.0) gives the following complicated error message {{{ Test.hs:7:13: error: • Couldn't match expected type ‘p’ with actual type ‘a’ because type variable ‘a’ would escape its scope This (rigid, skolem) type variable is bound by a pattern with constructor: Foo :: forall a. a -> Foo, in a pattern binding at Test.hs:7:9-13 • In the pattern: Foo x In a pattern binding: Foo x = Foo 1 In the expression: let Foo x = Foo 1 in return () | 7 | let Foo x = Foo 1 in | }}} GHC 7.10.1.2 gave a much more helpful and direct error message {{{ Test.hs:7:9: My brain just exploded I can't handle pattern bindings for existential or GADT data constructors. Instead, use a case-expression, or do-notation, to unpack the constructor. In the pattern: Foo x In a pattern binding: Foo x = Foo 1 In the expression: let Foo x = Foo 1 in return () }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15991> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #14252: ApplicativeDo: Add compiler message about irrefutable pattern matches and Monad constraints
by GHC 03 Dec '18

03 Dec '18

#14252: ApplicativeDo: Add compiler message about irrefutable pattern matches and Monad constraints -------------------------------------+------------------------------------- Reporter: mutantmell | Owner: (none) Type: feature | Status: new request | 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: -------------------------------------+------------------------------------- Add an error message to the compiler when ApplicativeDo desugaring: * requires a Monad constraint when a Functor/Applicative constraint is expected * Adding a lazy pattern match could allow the Functor/Applicative constraint bgamari suggests something like the following message: {{{#!hs ApplicativeDo is enabled yet Monad is required due to irrefutable pattern match; perhaps you want to make the match refutable by adding a ~? }}} Background: In GHC 8.2.1, ApplicativeDo desugaring was changed to require monad constraints when using a strict pattern match (see #13875 for details). While this behavior is a requirement for maintaining the intended semantics of ApplicativeDo, it is both a breaking change, and somewhat unintuitive (see #14249). Adding a message would provide both clarification around the requirement, and provide a simple resolution for the common use case. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14252> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7