April 2017 - ghc-tickets

[GHC] #13517: No warnings produced, yet the pattern matching fails at runtime.
by GHC 03 Apr '17

03 Apr '17

#13517: No warnings produced, yet the pattern matching fails at runtime. -------------------------------------+------------------------------------- Reporter: | Owner: (none) timotej.tomandl | Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple PatternMatchWarnings | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The code below should produce a warning about a non-exhaustive pattern in the failure, yet it compiles alright. {{{ #!div style="font-size: 80%" {{{#!haskell {-# OPTIONS_GHC -Wall -Werror #-} action :: (Monad m)=>t->m (Maybe a) action _=return Nothing failure :: (Monad m)=>Int->(m Int) failure x=do Just y<-action x return y main :: IO() main=do y<-failure 1 putStrLn $ (show y) }}} }}} The same should be the case if we replace the definition of failure with {{{ #!div style="font-size: 80%" {{{#!haskell failure :: (Monad m)=>Int->(m Int) failure x=(action x)>>=(\(Just y)->return y) }}} }}} yet once again no warnings are produced. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13517> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

Re: [GHC] #7780: GHC HEAD dll fails to build on Windows
by GHC 02 Apr '17

02 Apr '17

#7780: GHC HEAD dll fails to build on Windows ----------------------------------------+--------------------------------- Reporter: rassilon | Owner: igloo Type: bug | Status: closed Priority: normal | Milestone: Component: Build System | Version: Resolution: fixed | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------------+--------------------------------- Comment (by Sergei Trofimovich <slyfox@…>): In [changeset:"03e34256e2cba964adf6dcdb1682618f26400b3a/ghc" 03e34256/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="03e34256e2cba964adf6dcdb1682618f26400b3a" compiler/ghc.mk: fix GhcWithInterpreter=NO build failure When GhcWithInterpreter=NO is set in mk/build.mk build fails as: $ inplace/bin/dll-split compiler/stage2/build/.depend-v-dyn.haskell "DynFlags" ... Reachable modules from DynFlags out of date Please fix compiler/ghc.mk, or building DLLs on Windows may break (#7780) Extra modules: ByteCodeTypes InteractiveEvalTypes Signed-off-by: Sergei Trofimovich <slyfox(a)gentoo.org> }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7780#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13510: GHC panic with -fdefer-type-errors
by GHC 02 Apr '17

02 Apr '17

#13510: GHC panic with -fdefer-type-errors -------------------------------------+------------------------------------- Reporter: chrismwendt | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This program causes GHCi to panic: {{{ import Data.Monoid a = "" x :: () -> Int x b = a <> b }}} {{{ $ stack --version Version 1.3.2 x86_64 hpack-0.15.0 $ stack exec ghci program.hs GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /Users/chrismwendt/.ghci [1 of 1] Compiling Main ( program.hs, interpreted ) program.hs:6:12: warning: [-Wdeferred-type-errors] • Couldn't match expected type ‘Int’ with actual type ‘()’ • In the second argument of ‘(<>)’, namely ‘b’ In the expression: a <> b In an equation for ‘x’: x b = a <> b ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-apple-darwin): corePrepPgm [False] cobox_r1MZ = typeError @ 'VoidRep @ (Int :: *) ~# (() :: *) "program.hs:6:12: error:\n\ \ \\226\\128\\162 Couldn't match expected type \\226\\128\\152Int\\226\\128\\153 with actual type \\226\\128\\152()\\226\\128\\153\n\ \ \\226\\128\\162 In the second argument of \\226\\128\\152(<>)\\226\\128\\153, namely \\226\\128\\152b\\226\\128\\153\n\ \ In the expression: a <> b\n\ \ In an equation for \\226\\128\\152x\\226\\128\\153: x b = a <> b\n\ \(deferred type error)"# }}} Here's my ~/.ghci config: {{{ :set -fdefer-type-errors :set -XOverloadedStrings :set +t }}} Both -fdefer-type-errors and -XOVerloadedStrings are necessary to cause the panic. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13510> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #10976: Applicative Comprehensions
by GHC 02 Apr '17

02 Apr '17

#10976: Applicative Comprehensions -------------------------------------+------------------------------------- Reporter: davidar | Owner: Type: feature | Status: new request | Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: 8914 | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- As discussed on `ghc-devs`, when both the `MonadComprehensions` and `ApplicativeDo` language extensions are enabled, it should be possible to use comprehension-notation (in addition to do-notation) for `Applicative`s. This would allow, for example, an expression like {{{#!hs (\x y -> x + 2*y) <$> ZipList [1..10] <*> ZipList [10,20..100] }}} to also be written as {{{#!hs [ x + 2*y | x <- ZipList [1..10], y <- ZipList [10,20..100] ] }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10976> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #12490: ApplicativeDo and RebindableSyntax do not desugar as expected
by GHC 02 Apr '17

02 Apr '17

#12490: ApplicativeDo and RebindableSyntax do not desugar as expected -------------------------------------+------------------------------------- Reporter: AaronFriel | Owner: Type: bug | 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: -------------------------------------+------------------------------------- In a module with -XApplicativeDo, -XRebindableSyntax, and local definitions for everything in the Functor-Applicative-Monad hierarchy, do- notation always desugars to "join (... (return ...))" (or /s/return/pure/). This forces the result to have at least the constraints of join, which in my case is "IxMonad m". {{{#!hs {-# LANGUAGE RebindableSyntax, ApplicativeDo #-} module My where -- straightforward definitions of fmap, pure, (<*>), join, return, (>>=), (>>) and fail in terms of IxFunctor, IxPointed, IxApplicative, IxMonad fPure m = do a <- m b <- m pure (a, b) fReturn m = do a <- m b <- m return (a, b) }}} According to -ddump-ds, these desugar to: {{{#!hs fPure :: IxMonad m => m k1 k1 a -> m k1 k1 (a, a) fPure m = My.join ( My.(<*>) (My.fmap (\a b -> My.pure (a, b)) m) m ) fReturn :: IxMonad m => m k1 k1 a -> m k1 k1 (a, a) fReturn m = My.join ( My.(<*>) (My.fmap (\a b -> My.return (a, b)) m) m ) }}} But I would expect: {{{#!hs fPure m = My.(<*>) (My.fmap (\a b -> (a, b)) m) m fReturn m = -- same }}} It appears that when "return" is not from base, ApplicativeDo only partially desugars to the specification. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12490> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #11612: Bug in ApplicativeDo
by GHC 02 Apr '17

02 Apr '17

#11612: Bug in ApplicativeDo -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: high | 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: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I discovered a bug in `ApplicativeDo`. Fix coming shortly. The problem is illustrated by this test case, which I will add to `ado001.hs` in the testsuite: {{{ test11 :: M () test11 = do x1 <- a let x2 = x1 x3 <- b let x4 = c x5 = x4 return (const () (x1,x2,x3,x4)) }}} Which should give `(a | b)`, but gives `(a ; b)` in 8.0.1 RC. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11612> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #13507: Changes to environment files don't apply in GHCi on :reload
by GHC 01 Apr '17

01 Apr '17

#13507: Changes to environment files don't apply in GHCi on :reload -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: GHCi | 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: -------------------------------------+------------------------------------- Changes to (or creation of) package environment files don't apply in GHCi when the user performs a `:reload`. This is likely contrary to the user's expectation. This was first noted in Phab:D3392 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13507> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13474: GHC HEAD regression: Prelude.!!: index too large
by GHC 01 Apr '17

01 Apr '17

#13474: GHC HEAD regression: Prelude.!!: index too large -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.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: -------------------------------------+------------------------------------- `git-annex-6.20170321` from Hackage currently fails to build with GHC 8.2.1 and HEAD because it triggers this panic. Here's a simplified example that exhibits the issue: {{{#!hs {-# LANGUAGE BangPatterns #-} module Command.Vicfg where import qualified Data.Map as M class Default a where def :: a instance Default Int where def = 0 data Cfg = Cfg { cfgTrustMap :: M.Map Int Int , cfgGroupMap :: M.Map Int Int } defCfg :: Cfg -> Cfg defCfg curcfg = Cfg { cfgTrustMap = mapdef $ cfgTrustMap curcfg , cfgGroupMap = mapdef $ cfgGroupMap curcfg } where mapdef :: Default v => M.Map k v -> M.Map k v mapdef = M.map (const def) }}} {{{ $ /opt/ghc/8.2.1/bin/ghc Bug.hs -O1 [1 of 1] Compiling Command.Vicfg ( Bug.hs, Bug.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.2.0.20170321 for x86_64-unknown-linux): Prelude.!!: index too large }}} Note: * You need optimization (`-O1` or `-O2`) enabled. * You need to import `Map`/`map` for this panic to trigger, it seems, as redefining `Map`/`map` locally makes it work again. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13474> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12