February 2016 - ghc-tickets

Re: [GHC] #6166: Performance regression in mwc-random since 7.0.x
by GHC 29 Feb '16

29 Feb '16

#6166: Performance regression in mwc-random since 7.0.x -------------------------------------+------------------------------------- Reporter: bos | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.0.1 => 8.2.1 Comment: Nothing will be happening on this front for 8.0.1. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6166#comment:19> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #11370: Redundant superclass warnings being included in -Wall destroys the "3 Release Policy"
by GHC 29 Feb '16

29 Feb '16

#11370: Redundant superclass warnings being included in -Wall destroys the "3 Release Policy" -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 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: #11369 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- These redundant constraint warnings being in -Wall make it seemingly impossible for us to live up to the '3 Release Policy' in many situations. https://prime.haskell.org/wiki/Libraries/3-Release-Policy Consider the AMP: `(Monad m, Functor m)` gets used as a replacement for `Monad m` in many situations for compatibility with code before GHC 7.8, where that wants to call both `fmap` and something from `Monad`, but from 7.10+ that `Functor` is a redundant constraint. We have no backwards- facing 3-release-compatible constraint that someone could use in a type signature without warning to get both `fmap` and `return` that won't trigger this warning. Similarly if we split a class we can't advocate that folks use the subclass until the superclass is widely available or they'll get spammed with warnings. This affects splitting out `Semigroup` from `Monoid`. A similar issue arises with the `MonadFail` proposal as there is a stage around 8.4 where the 3-release-compatible advice would be to incur a `MonadFail` constraint, even when the active desguaring will be through `Monad`. I don't actually have a fix from the libraries side for the fact that with these showing up in -Wall, the 3 release policy doesn't work. Every single proposal the core libraries committee currently has in the works (except for adding `log1p`, `expm1`, etc. to Floating) is affected by this concern. One possible fix is to demote the redundant superclass warnings out of `-Wall`. This would resolve #11369 as well. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11370> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 35

[GHC] #11625: Data.Type.Equality is not Trustworthy
by GHC 29 Feb '16

29 Feb '16

#11625: Data.Type.Equality is not Trustworthy -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Core | Version: 7.10.3 Libraries | 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: -------------------------------------+------------------------------------- `Data.Type.Equality` is not inferred safe because it has unsafe imports. I believe it is safe, and should therefore claim `Trustworthy`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11625> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

Re: [GHC] #7325: threadDelay mistreats minBound and maxBound in some configurations
by GHC 29 Feb '16

29 Feb '16

#7325: threadDelay mistreats minBound and maxBound in some configurations -------------------------------------+------------------------------------- Reporter: joeyadams | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Runtime System | Version: 7.6.1 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: Incorrect result | Test Case: at runtime | base/tests/T8089 Blocked By: | Blocking: Related Tickets: #9722 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.0.1 => 8.2.1 Comment: This won't be fixed in 8.0.1. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7325#comment:12> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #11589: Reexports of wired-in packages don't work.
by GHC 29 Feb '16

29 Feb '16

#11589: Reexports of wired-in packages don't work. -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): Phab:D1926 | Wiki Page: -------------------------------------+------------------------------------- My fault. Have a patch. This bug is to make sure it goes into 8.0. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11589> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #11652: Cyclical dependencies aren't reported in pure functions
by GHC 29 Feb '16

29 Feb '16

#11652: Cyclical dependencies aren't reported in pure functions -------------------------------------+------------------------------------- Reporter: keynan | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC accepts Unknown/Multiple | invalid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- No compile error. found in 7.10.2 {{{#!hs main :: IO () main = do putStrLn $ "Hello " ++ (show x) where x = y + 1 y = x + 1 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11652> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #11134: Limit frequency of idle GCs
by GHC 29 Feb '16

29 Feb '16

#11134: Limit frequency of idle GCs -------------------------------------+------------------------------------- Reporter: dcturner | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Runtime | Version: 7.10.2 System | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In a server process with a relatively large heap (100s of MB) serving regular but relatively infrequent requests (~1 per sec) the idle GC runs after essentially every request which turns out to be extremely expensive: switching it off takes us from ~30% CPU to ~0.3% CPU. It is certainly useful have the GC run when idle but running it *every* time the process goes idle isn't necessary. It doesn't work to increase the delay (e.g. say -I2) as then the idle GC would never run, because the requests are rather regular. I'd quite like to be able to say something of the form "do a GC if idle for at least 0.3s as long as the idle GC has not run in the last 120s" - where 120s is another option passed to the RTS. Does this sound like a reasonable idea? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11134> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #11636: Promoting newtype destructor
by GHC 29 Feb '16

29 Feb '16

#11636: Promoting newtype destructor -------------------------------------+------------------------------------- Reporter: phadej | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 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: -------------------------------------+------------------------------------- given {{{ newtype LOL a = MkLOL { unLOL :: [[a]] } }}} I'd like to write {{{ type family UnLOL (lol :: LOL a) = (result :: [[a]]) | result -> lol type instance UnLOL ('MkLOL xss) = xss }}} This is currently not accepted, but AFAICS it should be injective, as `lol` is kind restricted. Especially the example in injective type families paper do not apply, as `UnLOL Int` is ill-kinded. With this GHC could infer `lol ~ MkLOL xss` from `UnLOL lol ~ xss`, so newtypes would be useful for type-level programming, as type (kind) synonyms cannot be partially applied. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11636> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #11658: Type synonym with context in pattern synonym
by GHC 28 Feb '16

28 Feb '16

#11658: Type synonym with context in pattern synonym -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature | Status: new request | 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: -------------------------------------+------------------------------------- {{{#!hs pattern :: (Num a, Eq a) => a pattern Fiskur = 42 }}} unlike {{{#!hs type Diskur a = Num a => a fiskur :: Num a => a fiskur = 42 }}} we cannot write {{{#!hs type Fugl a = (Num a, Eq a) => a pattern Fiskur :: Fugl a pattern Fiskur = 42 -- Exp.hs:54:18-19: error: … -- • No instance for (Eq a) arising from a pattern -- Possible fix: -- add (Eq a) to the context of -- the type signature for pattern synonym ‘Fiskur’: -- Fugl a -- • In the pattern: 42 -- In the declaration for pattern synonym ‘Fiskur’ -- Compilation failed. }}} Given that the story of pattern synonym contexts is more complicated than usual patterns given provided constraints, I know there are other issues (#11524, #10928). ---- For fun why not type synonym with provided and required constraints: {{{#!hs data T a where MkT :: (Show b) => a -> b -> T a f1 :: (Eq a, Num a) => T a -> String f1 (MkT 42 x) = show x type MKNUMPAT a b = (Num a, Eq a) => (Show b) => b -> T a -- pattern ExNumPat :: (Num a, Eq a) => (Show b) => b -> T a pattern ExNumPat :: MKNUMPAT a b pattern ExNumPat x = MkT 42 x }}} What would that mean in a regular type signature? `CE := CP + CR` where `EXNUMPAT a b` means the same as `EXNUMPAT' a b`? (#8581) {{{#!hs type MKNUMPAT' a b = (Num a, Eq a, Show b) => b -> T a -- This works: mkNumPat :: MKNUMPAT a b mkNumPat = ExNumPat }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11658> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

Re: [GHC] #7388: CAPI doesn't work with ghci
by GHC 28 Feb '16

28 Feb '16

#7388: CAPI doesn't work with ghci -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: T4012 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by hvr): Replying to [comment:10 bgamari]: > Can someone clarify what "CAPI" means in this context? Something like {{{#!hs {-# LANGUAGE CApiFFI #-} import Foreign.C foreign import capi "stdio.h printf" printfb :: CString -> CInt -> IO () }}} There was a minor improvement in the error-message since 7.10 however: With 7.10 you get the somewhat cryptic message: {{{ [1 of 1] Compiling T4012_B ( T4012_B.hs, interpreted ) ByteCodeLink: can't find label During interactive linking, GHCi couldn't find the following symbol: ghczuwrapperZC0ZCmainZCT4012zuBZCprintf This may be due to you not asking GHCi to load extra object files, archives or DLLs needed by your current session. Restart GHCi, specifying the missing library using the -L/path/to/object/dir and -lmissinglibname flags, or simply by naming the relevant files on the GHCi command line. Alternatively, this link failure might indicate a bug in GHCi. If you suspect the latter, please send a bug report to: glasgow-haskell-bugs(a)haskell.org }}} whereas with GHC 8.0 you get {{{ [1 of 1] Compiling T4012_B ( T4012_B.hs, interpreted ) Error: bytecode compiler can't handle some foreign calling conventions Workaround: use -fobject-code, or compile this module to .o separately. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7388#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0