- ghc-tickets - Haskell.org

[GHC] #15069: Missed SpecConstr opportunity
by GHC 20 Apr '18

20 Apr '18

#15069: Missed SpecConstr opportunity -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Keywords: SpecConstr | 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 you look at the final Core for `Csg.calc` in `nofib/real/fulsom` you'll see missed opportunities for `SpecConstr`. It has nested join points which look like this: {{{ join j (x :: Double) = Board (case x of { D# y -> ... }) ... in ....(j (D# v)).... }}} So the call to $j$ ends up with an explicit `(D# v)` argument, and `SpecConstr` should catch it. But alas it does not because this happends nestedly, and `SpecConstr` is worried about exponential blowup. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15069> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #11735: Optimize coercionKind
by GHC 20 Apr '18

20 Apr '18

#11735: Optimize coercionKind -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.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: -------------------------------------+------------------------------------- Currently, the `ForAllCo` case of `coercionKind` does an inefficient one- variable substitution. This could be improved by looking for nested `ForAllCo`s. Furthermore, perhaps we don't need an in-scope set and the full substitution machinery here. The subst is simply propagating the update of a tyvar's kind. No structural changes at all. No need for smart coercion constructors or other processing. So if we're going to optimize this, it might be worth making a specialized version of `subst_ty` and `subst_co` that operate over a `VarEnv Var` instead of a full substitution. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11735> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 87

[GHC] #13380: raiseIO# result looks wrong
by GHC 20 Apr '18

20 Apr '18

#13380: raiseIO# result looks wrong -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- `primops.txt.pp` includes the following note: > `raiseIO#` needs to be a primop, because exceptions in the `IO` monad must be ''precise'' - we don't want the strictness analyser turning one kind of bottom into another, as it is allowed to do in pure code. > > But we ''do'' want to know that it returns bottom after being applied to two arguments, so that this function is strict in `y` > {{{#!hs > f x y | x>0 = raiseIO blah > | y>0 = return 1 > | otherwise = return 2 > }}} I believe the "But we do" portion is, unfortunately, entirely wrong. From a user perspective, it is extremely strange to replace a precise exception with an imprecise one. That is, I strongly believe the above code should be considered ''lazy'' in `y`. The function `f` calculates an `IO` action; the value of `y` is only necessary to calculate that action if `x` is non- positive. We can, conservatively, say for certain that the second component of the result of `raiseIO#` (i.e., the "return value") is bottom. We can also say, given {{{#!hs case raiseIO# e s of (# s', r #) -> q }}} that `q` is dead (we could replace it by `(# s', undefined #)`). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13380> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 16

[GHC] #13276: Unboxed sums are not Typeable
by GHC 20 Apr '18

20 Apr '18

#13276: Unboxed sums are not Typeable -------------------------------------+------------------------------------- Reporter: Ben Gamari | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Keywords: typeable | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- While the Typeable machinery introduce in the type-indexed Typeable rework (#11011) is fully capable of representing unboxed sums, we currently don't allow this since it would require that we generate an enormous number of bindings in `GHC.Types`. This is because we need to generate both `TyCon` and `KindRep` bindings for each type constructor and its promoted data constructors. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13276> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #13261: Consider moving Typeable evidence generation wholly back to solver
by GHC 20 Apr '18

20 Apr '18

#13261: Consider moving Typeable evidence generation wholly back to solver -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new 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: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Since 91c6b1f54aea658b0056caec45655475897f1972 we have generated a set of bindings with each datatype definition which the compiler will refer to when constructing `Typeable` evidence. As described in the commit message, this came with a rather significant performance penalty, especially given that it is paid regardless of whether the code being compiled uses `Typeable`. The type-indexed Typeable implementation (#11011) augments these bindings with additional information allowing the kind of a type of be reconstructing at runtime (#10343). Unfortunately, this further blows up the cost of associated with Typeable binding generation. Some of the testsuite regressions are hard to swallow to say the least. While I'm still working out what can be done to reduce this cost, I do wonder whether the generating these bindings at the time of type definition is so wise. Relatively few users make use of Typeable and the cost is not negligible. Moreover, generating bindings for families of tycons (e.g. unboxed sums, which have thousands of type constructors and promoted data constructors) all at once produces a truly massive amount of code (albeit it only has to be done once). On the other hand, I suppose if Richard's dependent types story comes to fruition then perhaps the weight imposed by generating Typeable bindings at type-definition time might pull its weight. Anyways, just idle reflections. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13261> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #15012: "Iface type variable out of scope" when compiling with -c
by GHC 20 Apr '18

20 Apr '18

#15012: "Iface type variable out of scope" when compiling with -c -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Take these two files: {{{#!hs {-# LANGUAGE DeriveGeneric #-} {-# LANGUAGE TypeFamilies #-} module Foo where import GHC.Generics type FakeOut a = Int data family TyFamily y z data instance TyFamily a b = TyFamily Int (FakeOut b) deriving Generic1 }}} {{{#!hs module Bar where import Foo import GHC.Generics main :: IO () main = print $ from1 $ TyFamily 1 2 }}} And compile them like so: {{{ $ ghc -c Foo.hs $ ghc -c Bar.hs ./Foo.hi Declaration for Rep1_R:TyFamilyab Axiom branches Rep1_R:TyFamilyab: Iface type variable out of scope: b Cannot continue after interface file error }}} I can reproduce this with every version of GHC from 7.8.4 onward, so this is quite an old bug! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15012> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #15048: Fix mirroring of terminfo and haskeline
by GHC 19 Apr '18

19 Apr '18

#15048: Fix mirroring of terminfo and haskeline -------------------------------------+------------------------------------- Reporter: bgamari | Owner: hvr Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Trac & Git | 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: -------------------------------------+------------------------------------- These seem not to mirror from GitHub to git.haskell.org automatically, unlike most of the boot libraries. Looking at the mirroring configuration it appears that it was never configured for these packages, but there is no indication as to why. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15048> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #14997: mut_list_size calculation is off
by GHC 19 Apr '18

19 Apr '18

#14997: mut_list_size calculation is off -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: lowest | Milestone: Component: Runtime | Version: 8.5 System | 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: -------------------------------------+------------------------------------- Program: {{{ main = print (foldr (+) 0 [ 0 .. 10000 ] :: Int) }}} Compile: {{{ $ ghc-stage2 Main.hs -debug -rtsopts -O0 }}} Run: {{{ $ ./Main +RTS -Dg }}} It prints something like {{{ mut_list_size: 16 (0 vars, 0 arrays, 0 MVARs, 0 TVARs, 0 TVAR_WATCH_QUEUEs, 0 TREC_CHUNKs, 0 TREC_HEADERs, 0 ATOMIC_INVARIANTs, 0 INVARIANT_CHECK_QUEUEs, 0 others) }}} So there are two objects in the mut list, but `scavenge_mutable_list` wasn't able to find anything. This is curious, and it seems like a bug. Pretty much any program has this bug, `mut_list_size` and sum of objects found in the mut list never match. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14997> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #15018: Bump base's version number to 4.12.0.0 in HEAD
by GHC 19 Apr '18

19 Apr '18

#15018: Bump base's version number to 4.12.0.0 in HEAD -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: libraries | Version: 8.5 (other) | 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, `base` sits at version `4.11.0.0` in HEAD (which is the same version of `base` as shipped with GHC 8.4.1). This is making it difficult to adapt certain Hackage libraries to recent changes in `base`, such as moving `Data.Functor.Contravariant` into `base` (see the discussion [https://github.com/ekmett/contravariant/issues/44 here]). Before we can do this, here is a list of libraries that will need to have their upper version bounds on `base` bumped from `< 4.12` to `< 4.13`: * `array` * `deepseq` * `directory` * `filepath` * `ghc-boot-th` * `ghc-compat` * `ghci` * `haddock` * `haskeline` * `hpc` * `parallel` * `parsec` * `primitive` * `process` * `stm` * `template-haskell` * `terminfo` Some of these can be changed in-place, while others will require downstream changes. I'll update this ticket as I progress. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15018> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 18

[GHC] #13450: Better parse error for empy character literal
by GHC 19 Apr '18

19 Apr '18

#13450: Better parse error for empy character literal -------------------------------------+------------------------------------- Reporter: parsonsmatt | 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: Poor/confusing Unknown/Multiple | error message Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Empty character literals give an obscure error message. As an example, this code: {{{#!hs example = foo : bar where foo = '' bar = "asdf" }}} gives the following error when loaded in GHCi: {{{ err.hs:4:6: parse error (possibly incorrect indentation or mismatched brackets) }}} This has affected me once, as a beginner. I've seen it affect a few other beginners, and the error message isn't very helpful to figuring out what's wrong. It would be nice if a better error message could be reported. If there's a parse error on `''`, then GHC could report something like: {{{ err.hs:3:11: parse error on `''`. Note: Character literals may not be empty. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13450> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7