March 2017 - ghc-tickets

[GHC] #12650: Too many warnigns about consistentCafInfo
by GHC 04 Apr '17

04 Apr '17

#12650: Too many warnigns about consistentCafInfo -------------------------------------+------------------------------------- Reporter: nomeata | 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: -------------------------------------+------------------------------------- Building GHC with debug on yiedls in many (97!) warnings of the form {{{ WARNING: file compiler/stgSyn/CoreToStg.hs, line 252 $fFunctorIOEnv True False }}} The code in question is {{{ -- Assertion helper: this checks that the CafInfo on the Id matches -- what CoreToStg has figured out about the binding's SRT. The -- CafInfo will be exact in all cases except when CorePrep has -- floated out a binding, in which case it will be approximate. consistentCafInfo :: Id -> GenStgBinding Var Id -> Bool consistentCafInfo id bind = WARN( not (exact || is_sat_thing) , ppr id <+> ppr id_marked_caffy <+> ppr binding_is_caffy ) safe where safe = id_marked_caffy || not binding_is_caffy exact = id_marked_caffy == binding_is_caffy id_marked_caffy = mayHaveCafRefs (idCafInfo id) binding_is_caffy = topStgBindHasCafRefs bind is_sat_thing = occNameFS (nameOccName (idName id)) == fsLit "sat" }}} It would be nice to have less warnings, to make them more useful. I don’t know if the warning is not right, or if there is something that can be fixed about the thing it is warning about. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12650> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #12461: Document -O3
by GHC 04 Apr '17

04 Apr '17

#12461: Document -O3 -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Documentation Unknown/Multiple | bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- GHC accepts the flag -O3, but I can't find any documentation on it. What does it do? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12461> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #9596: Create monoidal category framework for arrow desugarer
by GHC 04 Apr '17

04 Apr '17

#9596: Create monoidal category framework for arrow desugarer -------------------------------------+------------------------------------- Reporter: spacekitteh | Owner: Type: task | spacekitteh Priority: normal | Status: new Component: GHC API | Milestone: 7.10.1 Keywords: | Version: Architecture: Unknown/Multiple | Operating System: Difficulty: Project (more | Unknown/Multiple than a week) | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- I'm going to put it into a GHC namespace (GHC.Arrows.Experimental, perhaps) and put instances for Arrow and such in there as well. In a later ticket I'll work on the desugarer, converting erverything into SMC combinators rather than Arrow combinators. The basic design is [blog.spacekitteh.moe/posts/new-monoidal-cats.html here] -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9596> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #13332: Report unrecognized pragmas earlier
by GHC 03 Apr '17

03 Apr '17

#13332: Report unrecognized pragmas earlier -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 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: -------------------------------------+------------------------------------- In the following example, I have a typo in the `UndecidableInstances` pragma (`LANGUAGE` is misspelled), however, GHC ''only'' reports that `UndecidableInstances` is required. This is very confusing, since it appears that I have enabled that pragma. {{{ {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE FlexibleInstances #-} {-# LANUGAGE UndecidableInstances #-} instance (Num [a]) => Num a }}} Only when I comment out the instance does GHC report that there is an unrecognized pragma, at which point it became obvious that there was a typo. It would be very helpful if GHC reported the warning about the unrecognized pragma before or at the same time as the error about needing `UndecidableInstances`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13332> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[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] #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

Re: [GHC] #7944: GHC goes into an apparently infinite loop at -O2
by GHC 31 Mar '17

31 Mar '17

#7944: GHC goes into an apparently infinite loop at -O2 -------------------------------------+------------------------------------- Reporter: bos | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: SpecConstr Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: #5550 #8852 | Differential Rev(s): Phab:D3404 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: ezyang (added) * status: new => patch * differential: => Phab:D3404 Comment: Huh, the commit that fixed this turned out to be something quite different from what I was imagining. It's actually b8b3e30a6eedf9f213b8a718573c4827cfa230ba (Axe RecFlag on TyCons.) I don't know if this change directly fixes the issue or if it's just a happy coincidence (ezyang, any thoughts?), but either way, I've added a regression test in Phab:D3404. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7944#comment:14> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13498: More storable instances?
by GHC 31 Mar '17

31 Mar '17

#13498: More storable instances? -------------------------------------+------------------------------------- Reporter: wyager | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: | Version: 8.0.1 libraries/base | Keywords: Storable, | Operating System: Unknown/Multiple Foreign, Ptr | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Is it intentional that we don't have {{{Storable}}} instances for ADTs like {{{Maybe}}} and {{{Either}}}, nor for things like {{{(,)}}}? This approach seems to work: https://gist.github.com/wyager/8443c3f5a9fc9b52dc28346bafdf409f Basically what the C compiler would do for a {{{union}}} type with a tag. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13498> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5