March 2016 - ghc-tickets

[GHC] #11639: `:print` being wacky
by GHC 29 Mar '16

29 Mar '16

#11639: `:print` being wacky ----------------------------------------+------------------------------- Reporter: TheKing42 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Linux Architecture: Unknown/Multiple | Type of failure: GHCi crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+------------------------------- {{{ $ ghci GHCi, version 7.10.3: http://www.haskell.org/ghc/ :? for help Prelude> let x = 1:x Prelude> :print x x = (_t1::Num a => [a]) Prelude> head _t1 ghc: panic! (the 'impossible' happened) (GHC version 7.10.3 for x86_64-unknown-linux): tcTyVarDetails a_avB Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11639> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #11725: Performance Regression from 7.8.3 to 7.10.3
by GHC 29 Mar '16

29 Mar '16

#11725: Performance Regression from 7.8.3 to 7.10.3 -------------------------------------+------------------------------------- Reporter: dominic | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Linux Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Some time ago I wrote a little test program for random number generation. Under 7.8.3 I get {{{ Total time 9.03s ( 9.15s elapsed) }}} Under 7.10.3 I get {{{ Total time 24.773s ( 25.288s elapsed) }}} Now of course it could be the libraries that I am using rather than GHC itself so I have tried to make them as similar as possible. For 7.8.3 I have {{{ build-depends: base ==4.7.0.1, mtl ==2.1.3.1, primitive == 0.6, mwc-random == 0.13.3.2, vector == 0.10.12.3, random ==1.1, random-fu == 0.2.6.2, random-source == 0.3.0.6 }}} For 7.10.3 I have {{{ build-depends: base ==4.8.2.0, mtl ==2.2, primitive == 0.6, mwc-random == 0.13.3.2, vector == 0.10.12.3, random ==1.1, random-fu == 0.2.6.2, random-source == 0.3.0.6 }}} So the only differences are in mtl and base. I don’t seem to be able to coax cabal into using mtl-2.2 for 7.8.3 with all the other required libraries. {{{ dominic@ghcPerformance:~$ cabal install 'random-source ==0.3.0.6' 'random- fu ==0.2.6.2' 'random ==1.1' 'primitive ==0.6' 'mwc-random ==0.13.3.2' 'mtl ==2.2' 'vector ==0.10.12.3' --with-ghc=ghc-7.10.3 Resolving dependencies... All the requested packages are already installed: mtl-2.2 mwc-random-0.13.3.2 primitive-0.6 random-1.1 random-fu-0.2.6.2 random-source-0.3.0.6 vector-0.10.12.3 Use --reinstall if you want to reinstall anyway. dominic@ghcPerformance:~$ cabal install 'random-source ==0.3.0.6' 'random- fu ==0.2.6.2' 'random ==1.1' 'primitive ==0.6' 'mwc-random ==0.13.3.2' 'mtl ==2.2' 'vector ==0.10.12.3' --with-ghc=ghc-7.8.3 Resolving dependencies... cabal: Could not resolve dependencies: trying: random-source-0.3.0.6/installed-70e... (user goal) next goal: mtl (user goal) rejecting: mtl-2.2.1, 2.2.0.1 (global constraint requires ==2.2) rejecting: mtl-2.2/installed-cc5..., 2.2 (conflict: random-source => mtl==2.1.3.1/installed-8bc...) rejecting: mtl-2.1.3.1/installed-8bc..., 2.1.3.1, 2.1.2, 2.1.1, 2.1, 2.0.1.1, 2.0.1.0, 2.0.0.0, 1.1.1.1, 1.1.1.0, 1.1.0.2, 1.1.0.1, 1.1.0.0, 1.0 (global constraint requires ==2.2) Backjump limit reached (change with --max-backjumps). }}} Cabal seems to be telling me that random-source-0.3.0.6 is the problem but if I look at the constraints for that package here https://hackage.haskell.org/package/random-source then I see {{{ mtl (>=1 && <3) }}} I am not sure how to proceed from here. I’d like to solve this myself but I don’t want to start building versions of ghc to see which change caused the regression without first eliminating mtl. Any ideas would be gratefully received. {{{ {-# LANGUAGE TemplateHaskell #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE FlexibleInstances #-} import Data.Random import Data.Random.Source import qualified System.Random.MWC as MWC import Control.Monad.Reader import Control.Monad.Primitive $(monadRandom [d| instance (PrimMonad m, s ~ PrimState m) => MonadRandom (ReaderT (MWC.Gen s) m) where getRandomWord16 = ask >>= lift . MWC.uniform getRandomWord32 = ask >>= lift . MWC.uniform getRandomWord64 = ask >>= lift . MWC.uniform |]) testUniform :: MonadRandom m => Int -> m [Double] testUniform n = replicateM (fromIntegral n) (sample stdUniform) n :: Int n = 10^7 main :: IO () main = do seed <- MWC.create xs <- runReaderT (testUniform n) seed print (sum xs / fromIntegral n) }}} This cabal file will build this on 7.8.3 {{{ name: PerfTest8 version: 0.1.0.0 homepage: TBD license: MIT author: Dominic Steinitz maintainer: idontgetoutmuch(a)gmail.com category: System build-type: Simple cabal-version: >=1.10 executable Random8 main-is: TestMwcViaRandomSource.hs build-depends: base ==4.7.0.1, mtl ==2.1.3.1, primitive == 0.6, mwc-random == 0.13.3.2, vector == 0.10.12.3, random ==1.1, random-fu == 0.2.6.2, random-source == 0.3.0.6 default-language: Haskell2010 }}} This cabal file will build this on 7.10.3 {{{ name: PerfTest10 version: 0.1.0.0 homepage: TBD license: MIT author: Dominic Steinitz maintainer: idontgetoutmuch(a)gmail.com category: System build-type: Simple cabal-version: >=1.10 executable Random10 main-is: TestMwcViaRandomSource.hs build-depends: base ==4.8.2.0, mtl ==2.2, primitive == 0.6, mwc-random == 0.13.3.2, vector == 0.10.12.3, random ==1.1, random-fu == 0.2.6.2, random-source == 0.3.0.6 default-language: Haskell2010 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11725> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

Re: [GHC] #7411: Exceptions are optimized away in certain situations
by GHC 29 Mar '16

29 Mar '16

#7411: Exceptions are optimized away in certain situations -------------------------------------+------------------------------------- Reporter: SimonHengel | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: seq, deepseq, | evaluate, exceptions Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: at runtime | simplCore/should_fail/T7411 Blocked By: | Blocking: Related Tickets: #5129 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari <ben@…>): In [changeset:"aa611746aa860e1884c9ad623d6939791f2645ff/ghc" aa61174/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="aa611746aa860e1884c9ad623d6939791f2645ff" users-guide: Add references to various issues in bugs section Test Plan: Read it Reviewers: austin Reviewed By: austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2052 GHC Trac Issues: #7411, #11197, #11554, #11715 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7411#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #1965: Allow unconstrained existential contexts in newtypes
by GHC 29 Mar '16

29 Mar '16

#1965: Allow unconstrained existential contexts in newtypes -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): But the `Some` at the link is this: {{{ data Some tag :: (k -> *) -> * where This :: !(tag t) -> Some k tag }}} There's no reason why this can't be a `newtype` today, is there? So it doesn't look relevant to this ticket. (Except I suppose that if comment:9 was implemented, it'd be efficient already.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1965#comment:24> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #11386: Improve error message
by GHC 28 Mar '16

28 Mar '16

#11386: Improve error message -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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: -------------------------------------+------------------------------------- {{{ Prelude> class (A, B) <interactive>:16:8: error: Unexpected type ‘A’ In the class declaration for ‘GHC.Classes.(%,%)’ A class declaration should have form class GHC.Classes.(%,%) a b where ... }}} in 7.10.2 it gave the more sensible {{{ ghci> class (A, B) <interactive>:30:7: Malformed head of type or class declaration: (A, B) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11386> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #11755: Seed unsafeGlobalDynFlags with enough information to use ppr
by GHC 28 Mar '16

28 Mar '16

#11755: Seed unsafeGlobalDynFlags with enough information to use ppr -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari 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: -------------------------------------+------------------------------------- At the moment the pretty-printer isn't functional if used before `DynFlags` is initialized by `initGhcMonad`. In particular things like `pprPanic` aren't usable since `unsafeGlobalDynFlags` isn't yet initialized. This is quite annoying during development. It seems like it should be possible to seed `unsafeGlobalDynFlags` with some minimal `DynFlags`, presumably with rather verbose output (as this is presumably what you want when debugging a compiler crash early in startup). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11755> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #10853: Refine addTopDecls
by GHC 28 Mar '16

28 Mar '16

#10853: Refine addTopDecls -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Template | Version: 7.10.2 Haskell | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- This suggested refactoring/documentation task is spurred on by #10486. Readers do not have to read that ticket to understand this task. Currently, `addTopDecls` is restricted in what it can add. In an email exchange with Geoff Mainland (the original implementor of `addTopDecls`), it was unclear exactly why this restriction is in place. So, I propose lifting the restriction. We do have to be careful about ordering. As it is currently implemented, here is what happens: {{{ -- region A, including everything up to but not including a top-level splice $( {- region B, the contents of a top-level splice -} ) -- region C, everything after the splice }}} In addition to those regions, we also have {{{ -- region D, consisting of all declarations added with `addTopDecls`. }}} By reading the code (`TcRnDriver.tc_rn_src_decls`), it seems that the expected behavior should be this: 1. Rename region A. Anything defined in other regions is not in scope. 2. Rename region D, with declarations from region A in scope. 3. Type-check regions A and D together. 4. When running TH code in region B, all declarations from A and D are in scope and can be accessed via `reify` and friends. 5. Combine regions B and C together, and recur to step 1 (where the combined B and C is now a new region A). This all means that A and D are mutually recursive w.r.t. the type-checker but not the renamer. This is a bit peculiar, but not terrible. For example, this means that there could be a function whose definition is in A and type signature in D. Proper mutual recursion would be hard (impossible?) without better renaming support. In any case, I don't see a reason to restrict what's allowed in `addTopDecls`. So, at a minimum, I propose: * Remove restrictions in `addTopDecls` * Document `addTopDecls` generally * Document the above behavior, detailing the interaction between these regions Perhaps better, we could do: * Remove restrictions in `addTopDecls` * Rejigger the implementation of `addTopDecls` to lump region D in with B and C. This looks quite straightforward, and it makes for a simpler story about mutual recursion. This is a potentially-breaking change, if existing code has, say, a function defined in A with its type signature in D. * Document the new, simpler behavior Regardless of which proposal we go with, some testing is in order, to make sure that this is all correct. I've done no testing in formulating this ticket, just reading code. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10853> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #11754: Error in optCoercion
by GHC 28 Mar '16

28 Mar '16

#11754: Error in optCoercion -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | 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: -------------------------------------+------------------------------------- This program fails Lint after a run of the simplifier. {{{ {-# LANGUAGE TypeOperators, UndecidableSuperClasses, KindSignatures, TypeFamilies, FlexibleContexts #-} module T11728a where import Data.Kind import Data.Void newtype K a x = K a newtype I x = I x data (f + g) x = L (f x) | R (g x) data (f × g) x = f x :×: g x class Differentiable (D f) => Differentiable f where type D (f :: Type -> Type) :: Type -> Type instance Differentiable (K a) where type D (K a) = K Void instance Differentiable I where type D I = K () instance (Differentiable f₁, Differentiable f₂) => Differentiable (f₁ + f₂) where type D (f₁ + f₂) = D f₁ + D f₂ instance (Differentiable f₁, Differentiable f₂) => Differentiable (f₁ × f₂) where type D (f₁ × f₂) = (D f₁ × f₂) + (f₁ × D f₂) }}} Originally reported in #11728, but it's a totally different problem. Richard has nailed it already... patch coming from him. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11754> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #11473: Levity polymorphism checks are inadequate
by GHC 28 Mar '16

28 Mar '16

#11473: Levity polymorphism checks are inadequate -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple LevityPolymorphism | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Ben found {{{ {-# LANGUAGE PolyKinds, TypeFamilies, MagicHash, DataKinds, TypeInType, RankNTypes #-} import GHC.Exts import GHC.Types type family Boxed (a :: k) :: * type instance Boxed Char# = Char type instance Boxed Char = Char class BoxIt (a :: TYPE lev) where boxed :: a -> Boxed a instance BoxIt Char# where boxed x = C# x instance BoxIt Char where boxed = id hello :: forall (lev :: Levity). forall (a :: TYPE lev). BoxIt a => a -> Boxed a hello x = boxed x {-# NOINLINE hello #-} main :: IO () main = do print $ boxed 'c'# print $ boxed 'c' print $ hello 'c' print $ hello 'c'# }}} This is plainly wrong because we have a polymorphic function `boxed` that is being passed both boxed and unboxed arguments. You do get a Lint error with `-dcore-lint`. But the original problem is with the type signature for `boxed`. We should never have a levity-polymorphic type to the left of an arrow. To the right yes, but to the left no. I suppose we could check that in `TcValidity`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11473> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 18

Re: [GHC] #4114: Add a flag to remove/delete intermediate files generated by GHC
by GHC 28 Mar '16

28 Mar '16

#4114: Add a flag to remove/delete intermediate files generated by GHC -------------------------------------+------------------------------------- Reporter: guest | Owner: kaiha Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #2258 | Differential Rev(s): Phab:D2021 Wiki Page: | Phab:D2050 -------------------------------------+------------------------------------- Comment (by Tamar Christina <tamar@…>): In [changeset:"49b9d80a4666504f3f3524928c9ae7cc436bb8ba/ghc" 49b9d80a/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="49b9d80a4666504f3f3524928c9ae7cc436bb8ba" Do not test for existence of the executable Summary: The test for the existence of the executable breaks on MS Windows. It is furthermore needless, because if the test can be executed the executable is obviously there. Reviewers: austin, bgamari, Phyx Reviewed By: Phyx Subscribers: Phyx, thomie Differential Revision: https://phabricator.haskell.org/D2050 GHC Trac Issues: #4114 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4114#comment:29> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0