May 2016 - ghc-tickets

[GHC] #9399: CPP does not process test case enum01.hs correctly
by GHC 25 May '16

25 May '16

#9399: CPP does not process test case enum01.hs correctly -------------------------------------+------------------------------------- Reporter: jrp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.8.3 Keywords: cpp | Operating System: MacOS X Architecture: x86_64 (amd64) | Type of failure: GHC Difficulty: Unknown | rejects valid program Blocked By: | Test Case: enum01.hs Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- The printTest cpp macro does not seem to be being applied in the test suite test enum01.hs (libraries/base) {{{ > ghci -cpp enum01.hs GHCi, version 7.8.3: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. [1 of 1] Compiling Main ( enum01.hs, interpreted ) enum01.hs:91:3: Not in scope: ‘printTest’ enum01.hs:92:3: Not in scope: ‘printTest’ : }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9399> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 18

[GHC] #8914: Remove unnecessary constraints from MonadComprehensions and ParallelListComp
by GHC 25 May '16

25 May '16

#8914: Remove unnecessary constraints from MonadComprehensions and ParallelListComp -------------------------------------------+------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Difficult (2-5 days) | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: -------------------------------------------+------------------------------- Many parts of MonadComprehensions don't actually require monads instance, the following could do with a `Functor` constraint {{{ fmapM :: Monad m => (a -> b) -> m a -> m b fmapM f xs = [ f x | x <- xs ] }}} and I don't see any reason why the class `MonadZip` (from [http://hackage.haskell.org/package/base-4.4.0.0/docs/Control-Monad- Zip.html Control.Monad.Zip]) requires a `Monad` constraint rather a `Functor` constraint: {{{ class Functor f => FunctorZip f where fzip :: f a -> f b -> f (a,b) fzip = fzipWith (,) fzipWith :: (a -> b -> c) -> f a -> f b -> f c fzipWith f fa fb = fmap (uncurry f) (fzip fa fb) funzip :: f (a,b) -> (f a, f b) funzip fab = (fmap fst fab, fmap snd fab) }}} with the laws {{{ fmap (f *** g) (fzip fa fb) = fzip (fmap f fa) (fmap g fb) fmap (const ()) fa = fmap (const ()) fb ==> funzip (fzip fa fb) = (fa, fb) }}} Same with `Applicative` (see ApplicativeDo): {{{ liftA2 :: Applicative f => (a -> b -> c) -> f a -> f b -> f c liftA2 f a1 a2 = [ f x1 x2 | x1 <- a1, x2 <- a2 ] }}} The reason I bring this up is because I'm writing a DSL that uses length- indexed vectors whose `Functor` and `FunctorZip` instances are trivial but whose `Monad` instance is [http://stackoverflow.com/questions/5802628 /monad-instance-of-a-number-parameterised-vector complicated] and not need. This proposal shares a similar rationale as ApplicativeDo. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8914> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #12016: Allow wildcards in type synonyms and data declarations
by GHC 25 May '16

25 May '16

#12016: Allow wildcards in type synonyms and data declarations -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature | Status: new request | Priority: lowest | Milestone: Component: Compiler | Version: (Parser) | 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 data Konst a _ = Konst a type Const a _ = a type Tagged _ b = b type Forget m a _ = a -> m }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12016> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #11581: TypeError requires UndecidableInstances unnecessarily
by GHC 25 May '16

25 May '16

#11581: TypeError requires UndecidableInstances unnecessarily -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: feature | Status: new request | Priority: low | Milestone: Component: Compiler | Version: 8.0.1-rc2 (Type checker) | 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: -------------------------------------+------------------------------------- The example from the `TypeError` documentation {{{ type family ByteSize x where ByteSize Word16 = 2 ByteSize Word8 = 1 ByteSize a = TypeError (Text "The type " :<>: ShowType a :<>: Text " is not exportable.") }}} requires `UndecidableInstances`: {{{ BS.hs:11:5: error: • The type family application ‘(TypeError ...)’ is no smaller than the instance head (Use UndecidableInstances to permit this) • In the equations for closed type family ‘ByteSize’ In the type family declaration for ‘ByteSize’ }}} Obviously there's no real danger of undecidability here. I tried changing the declaration of `TypeError` to {{{ type family TypeError :: ErrorMessage -> b where }}} but it didn't help. Same error. Is that a bug? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11581> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

Re: [GHC] #5522: mc03 -O -fliberate-case -fspec-constr runs out of memory
by GHC 25 May '16

25 May '16

#5522: mc03 -O -fliberate-case -fspec-constr runs out of memory -------------------------------------+------------------------------------- Reporter: btutt | Owner: simonpj Type: bug | Status: closed Priority: normal | Milestone: Component: Test Suite | Version: 7.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: performance bug | deSugar/should_run/mc03, | deSugar/should_run/T5522 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * testcase: mc03 => deSugar/should_run/mc03, deSugar/should_run/T5522 * status: new => closed * resolution: => fixed Comment: I added the original report (`mc03 -O -fliberate-case -fspec-constr`) as test, with a memory limit of 1 gigabyte. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5522#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5522: mc03 -O -fliberate-case -fspec-constr runs out of memory
by GHC 25 May '16

25 May '16

#5522: mc03 -O -fliberate-case -fspec-constr runs out of memory -------------------------------------+------------------------------------- Reporter: btutt | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: mc03 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Comment (by Thomas Miedema <thomasmiedema@…>): In [changeset:"5020bc8fd2a99a557f45ea5abf8240ac995cc03d/ghc" 5020bc8/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="5020bc8fd2a99a557f45ea5abf8240ac995cc03d" Testsuite: add a test for #5522 (-fliberate-case -fspec-constr) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5522#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12111: prof build flavour doesn't work
by GHC 25 May '16

25 May '16

#12111: prof build flavour doesn't work -------------------------------------+------------------------------------- Reporter: osa1 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | 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 with `prof` flavour on a fresh build doesn't work. I'm currently getting {{{ compiler/utils/Outputable.hs-boot:1:8: error: Failed to load interface for ‘Prelude’ Perhaps you haven't installed the "p_dyn" libraries for package ‘base-4.9.0.0’? Use -v to see a list of the files searched for. }}} In addition, I don't see any profiling flags passes to GHC in `prof.mk` (like `-fprof-auto`), so I'm not sure how effective default profiling build is. Am I missing something or do users need to add those manually to `GhcStage2HcOpts`? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12111> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

Re: [GHC] #7190: GHC's -fprof-auto does not work with LINE pragmas
by GHC 25 May '16

25 May '16

#7190: GHC's -fprof-auto does not work with LINE pragmas -------------------------------------+------------------------------------- Reporter: timthelion | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.4.2 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 osa1): I'm going over cost-center-related tickets -- does anyone know how do I test and close this? As far as I can see `.prof.sample` files are not good enough for testing purposes. For example, I created a `.prof.sample` for testing this, but if I remove a random line in that file the test is still accepted. What am I doing wrong? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7190#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12114: GHC rejects injective type family
by GHC 25 May '16

25 May '16

#12114: GHC rejects injective type family -------------------------------------+------------------------------------- Reporter: MikeIzbicki | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Type checker) | 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: -------------------------------------+------------------------------------- The following injective type family fails to compile in GHC 8.0 {{{ type family Snoc (xs :: [k]) (y::k) = r | r -> xs y where Snoc '[] y = '[y] Snoc (x ': xs) y = x ': (Snoc xs y) }}} The error message is {{{ • Type family equations violate injectivity annotation: forall k (y :: k). Snoc '[] y = '[y] -- Defined at FAlgebra.hs:49:5 forall k (xs :: [k]) (x :: k) (y :: k). Snoc (x : xs) y = x : Snoc xs y -- Defined at FAlgebra.hs:52:5 • In the equations for closed type family ‘Snoc’ In the type family declaration for ‘Snoc’ }}} I think the problem is related to injectivity rule 5 from [this page](https://ghc.haskell.org/trac/ghc/wiki/InjectiveTypeFamilies) being too conservative. In particular, if you substitute `'[]` for `Snoc xs y` in the RHS of the second rule, then the two rules will unify but have different LHSs. This substitution is invalid, however, because the `Snoc` type family will never result in an empty list. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12114> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #12117: Thread by forkIO freezes (while read :: Int if error appears) when compiled with -threaded option
by GHC 25 May '16

25 May '16

#12117: Thread by forkIO freezes (while read :: Int if error appears) when compiled with -threaded option -----------------------------------------+--------------------------------- Reporter: wapxmas | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: -threaded, freeze | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -----------------------------------------+--------------------------------- I attached program to reproduce bug. While running you need type "abc" then "1": 1. if build with "ghc -threaded concbug.hs" - code after "threadDelay_ t" on 29 is never run. 2. if build as "ghc concbug.hs" - program work as expected -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12117> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3