December 2015 - ghc-tickets

[GHC] #10819: Can't generate data decls deriving multiparam type classes with TH
by GHC 14 Dec '15

14 Dec '15

#10819: Can't generate data decls deriving multiparam type classes with TH -------------------------------------+------------------------------------- Reporter: spinda | Owner: Type: feature | Status: new request | Priority: normal | Milestone: 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 applies to both data declarations and (more commonly) newtypes. Example: {{{ {-# LANGUAGE GeneralizedNewtypeDeriving #-} newtype T a = X { unT :: State Int a } deriving (MonadState Int) }}} The newtype declaration is impossible to express in Template Haskell's AST, as the field for the derived classes is {{{[Name]}}} when it should really be {{{Cxt}}}. A workaround is to generate a {{{StandaloneDerivD}}} for each derived multiparam class, but this requires that the user enable the {{{StandaloneDeriving}}} extension which can be unintuitive, especially as there's no way (as far as I can tell) to detect whether this extension is enabled and report a proper error message if it isn't. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10819> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #3738: Typechecker floats stuff out of INLINE right hand sides
by GHC 14 Dec '15

14 Dec '15

#3738: Typechecker floats stuff out of INLINE right hand sides -------------------------------------+------------------------------------- Reporter: rl | Owner: igloo Type: bug | Status: closed Priority: normal | Milestone: 7.0.1 Component: Compiler | Version: 6.13 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: T3738 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by bgamari: Old description: > Small program: > {{{ > foo :: Num a => [a] -> a > {-# INLINE foo #-} > foo = go 0 > where > go m (n:ns) = m `seq` go (m+n) ns > go m [] = m > > bar :: [Int] -> Int > {-# INLINE bar #-} > bar = foo > }}} > Here is what `bar` looks like in the interface file: > {{{ > a6de4c46e53e565ed25ab5a38910e9cb > $wgo :: GHC.Prim.Int# -> [GHC.Types.Int] -> GHC.Prim.Int# > {- Arity: 2, HasNoCafRefs, Strictness: LS -} > 6838e3faa095285614477ebc92f54987 > bar :: [GHC.Types.Int] -> GHC.Types.Int > {- Arity: 1, HasNoCafRefs, Strictness: Sm, Inline: INLINE, > Unfolding: InlineRule: (arity 0 False) (Foo.bar_foo) -} > 5d06906ae99b9aefa1c6d251c3f2fc46 > bar_foo :: [GHC.Types.Int] -> GHC.Types.Int > {- Arity: 1, HasNoCafRefs, Strictness: Sm, > Unfolding: InlineRule: (arity 0 True) (\ w :: [GHC.Types.Int] -> > case @ GHC.Types.Int > Foo.$wgo 0 w of ww { DEFAULT -> > GHC.Types.I# ww }) -} > }}} > Note that the loop has disappeared from `bar`'s unfolding. Also, > `bar_foo` doesn't have an INLINE pragma. > > Incidentally, GHC specialises `foo` here and the specialisation doesn't > get an INLINE pragma, either: > {{{ > foo :: forall a. GHC.Num.Num a => [a] -> a > {- Arity: 1, HasNoCafRefs, Strictness: L, Inline: INLINE, > Unfolding: InlineRule: (arity 1 False) ... -} > > foo_$sfoo :: [GHC.Types.Int] -> GHC.Types.Int > {- Arity: 1, HasNoCafRefs, Strictness: Sm, > Unfolding: InlineRule: (arity 0 False) ... -} > > "SPEC Foo.foo [GHC.Types.Int]" ALWAYS forall $dNum :: GHC.Num.Num > GHC.Types.Int > Foo.foo @ GHC.Types.Int $dNum = Foo.foo_$sfoo > }}} New description: Small program: {{{#!hs foo :: Num a => [a] -> a {-# INLINE foo #-} foo = go 0 where go m (n:ns) = m `seq` go (m+n) ns go m [] = m bar :: [Int] -> Int {-# INLINE bar #-} bar = foo }}} Here is what `bar` looks like in the interface file: {{{ a6de4c46e53e565ed25ab5a38910e9cb $wgo :: GHC.Prim.Int# -> [GHC.Types.Int] -> GHC.Prim.Int# {- Arity: 2, HasNoCafRefs, Strictness: LS -} 6838e3faa095285614477ebc92f54987 bar :: [GHC.Types.Int] -> GHC.Types.Int {- Arity: 1, HasNoCafRefs, Strictness: Sm, Inline: INLINE, Unfolding: InlineRule: (arity 0 False) (Foo.bar_foo) -} 5d06906ae99b9aefa1c6d251c3f2fc46 bar_foo :: [GHC.Types.Int] -> GHC.Types.Int {- Arity: 1, HasNoCafRefs, Strictness: Sm, Unfolding: InlineRule: (arity 0 True) (\ w :: [GHC.Types.Int] -> case @ GHC.Types.Int Foo.$wgo 0 w of ww { DEFAULT -> GHC.Types.I# ww }) -} }}} Note that the loop has disappeared from `bar`'s unfolding. Also, `bar_foo` doesn't have an INLINE pragma. Incidentally, GHC specialises `foo` here and the specialisation doesn't get an INLINE pragma, either: {{{ foo :: forall a. GHC.Num.Num a => [a] -> a {- Arity: 1, HasNoCafRefs, Strictness: L, Inline: INLINE, Unfolding: InlineRule: (arity 1 False) ... -} foo_$sfoo :: [GHC.Types.Int] -> GHC.Types.Int {- Arity: 1, HasNoCafRefs, Strictness: Sm, Unfolding: InlineRule: (arity 0 False) ... -} "SPEC Foo.foo [GHC.Types.Int]" ALWAYS forall $dNum :: GHC.Num.Num GHC.Types.Int Foo.foo @ GHC.Types.Int $dNum = Foo.foo_$sfoo }}} -- -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3738#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #11053: Add a warning for pattern synonyms without signatures
by GHC 14 Dec '15

14 Dec '15

#11053: Add a warning for pattern synonyms without signatures -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: newcomer | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- It is accepted as good style that top-level definitions should have type signatures. Pattern synonyms seem no different to me in this regard so I think it would be good if GHC warned if there was a pattern synonym definition which lacked a type signature. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11053> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #11189: bang pattern parsing inconsistency
by GHC 14 Dec '15

14 Dec '15

#11189: bang pattern parsing inconsistency -------------------------------------+------------------------------------- Reporter: osa1 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 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: -------------------------------------+------------------------------------- {{{#!haskell -- Works f2 (!x, !y) = [x, y] -- Parse error on input '!' len1 lst = case lst of [] -> 0 (!x : !xs) -> 1 + len1 xs -- Parse error on input '!' len2 [] = 0 len2 (!x : !xs) = 1 + len xs }}} Tried with: HEAD, 7.10.2. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11189> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #11217: Empty GADT-style declaration accepted without extensions
by GHC 14 Dec '15

14 Dec '15

#11217: Empty GADT-style declaration accepted without extensions -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 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 module compiles without complaint: {{{#!hs module Bug where data Foo where }}} It should require `-XGADTSyntax`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11217> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

Re: [GHC] #5615: ghc produces poor code for `div` with constant powers of 2.
by GHC 14 Dec '15

14 Dec '15

#5615: ghc produces poor code for `div` with constant powers of 2. -------------------------------------+------------------------------------- Reporter: Lennart | Owner: | daniel.is.fischer Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.4.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86 Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by maoe): * cc: maoe (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5615#comment:24> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10741: add flag to dump module and package dependencies
by GHC 14 Dec '15

14 Dec '15

#10741: add flag to dump module and package dependencies -------------------------------------+------------------------------------- Reporter: elaforge | 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 Revisions: | -------------------------------------+------------------------------------- You can already dump module and package dependencies with -M -include-pkg- deps, but it wants to modify a Makefile, so it's not so convenient for things that are not make. For other build systems, it would be convenient to get this on stdout in an easily parseable form. Say X/A.hs imports Y/B.hs, which imports Z/C.hs, and they all use package 'base' and 'containers': {{{ % ghc -Mstdout X/A.hs X/A.h Y/B.hs Y/B.hs Z/C.hs base containers % }}} I don't know about what the output format should be, but assuming no newlines in filenames, and package names never have spaces, it seems simplest to do something like: [src ++ "\n" ++ dest ++ "\n" | (src, dest) <- moduleDeps] ++ "\n" ++ unwords packageDeps It could use haskell syntax like --info, but then you'd need a full haskell parser just to read it, which is not a problem for shake, but probably inconvenient for other build systems. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10741> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #10732: Legal Bang Patterns cannot parse
by GHC 13 Dec '15

13 Dec '15

#10732: Legal Bang Patterns cannot parse -------------------------------------+------------------------------------- Reporter: rem | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 (Parser) | Keywords: Bang | Operating System: Unknown/Multiple Pattern Parser | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- According to the syntax provided by GHC user guide pat ::= !pat Both !!pat and pat : !pat should be accepted, but GHC gives parsing error. For detail see http://stackoverflow.com/questions/31790327/where-can- bangpatterns-appear -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10732> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #11209: Please add platform detection support for sh4 (Hitachi SuperH)
by GHC 13 Dec '15

13 Dec '15

#11209: Please add platform detection support for sh4 (Hitachi SuperH) --------------------------------+------------------------------------- Reporter: glaubitz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: Other | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------+------------------------------------- Hello! I am currently bootstrapping ghc for sh4 in Debian. In order to get the ghc build scripts detect sh4 as a valid architecture, I had to make local changes to aclocal.m4. With these changes, sh4 is properly detected as an architecture and I can both cross-build for sh4 as well as build ghc on this platform natively. Please apply the supplied patch so that we do not have to carry this patch in the Debian package [1] anymore. Thanks, Adrian > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=807108 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11209> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

Re: [GHC] #7161: hSetNewlineMode and hSetEncoding can be performed on closed and semi-closed handles
by GHC 13 Dec '15

13 Dec '15

#7161: hSetNewlineMode and hSetEncoding can be performed on closed and semi-closed handles -------------------------------------+------------------------------------- Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Core Libraries | Version: 7.6.1-rc1 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: | -------------------------------------+------------------------------------- Changes (by thomie): * status: infoneeded => new * cc: ekmett (added) Old description: > The `hSetNewlineMode` and `hSetEncoding` functions from > `GHC/IO/Handle.hs` do not check that the Handle is in an open mode. It is > possible to use them on closed handles. hSetEncoding on a closed Handle > triggers a segfault. Similarly, the operations are also both possible on > semi-closed handles, and given the way hGetContents is implemented, this > will affect the result of hGetContents which is clearly against the > intention of the hGetContents/semi-closed stuff. > > Both functions use the `withAllHandles__` helper. Unlike similar helpers > like `wantReadableHandle_` this one doesn't do any handle mode checking. > > Additionally, `hSetBuffering` and `hSetBinary` mode also use the > `withAllHandles__` pattern and don't obviously check for an open handle > but I've not verified this. New description: The `hSetNewlineMode` and `hSetEncoding` functions from `GHC/IO/Handle.hs` do not check that the Handle is in an open mode. It is possible to use them on closed handles. hSetEncoding on a closed Handle triggers a segfault. Similarly, the operations are also both possible on semi-closed handles, and given the way hGetContents is implemented, this will affect the result of hGetContents which is clearly against the intention of the hGetContents/semi-closed stuff. Both functions use the `withAllHandles__` helper. Unlike similar helpers like `wantReadableHandle_` this one doesn't do any handle mode checking. Additionally, `hSetBuffering` and `hSetBinaryMode` mode also use the `withAllHandles__` pattern and don't obviously check for an open handle but I've not verified this. -- Comment: With or without segfaults, this could be fixed. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7161#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0