July 2014 - ghc-tickets

[GHC] #8912: Documentation stale: implicit-parameter constraints seem to be allowed in instance declarations now.
by GHC 25 Aug '14

25 Aug '14

#8912: Documentation stale: implicit-parameter constraints seem to be allowed in instance declarations now. -------------------------------------+------------------------------------- Reporter: andreas.abel | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.6.3 Keywords: implicit- | Operating System: Unknown/Multiple parameter instance-constraints | Type of failure: Documentation Architecture: Unknown/Multiple | bug Difficulty: Easy (less than 1 | Test Case: hour) | Blocking: Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- http://www.haskell.org/ghc/docs/7.6.3/html/users_guide/other-type- extensions.html#implicit-parameters says: You can't have an implicit parameter in the context of a class or instance declaration. For example, both these declarations are illegal: {{{ class (?x::Int) => C a where ... instance (?x::a) => Foo [a] where ... }}} However, ghc 7.6.3 seems to accept this now: {{{ {-# LANGUAGE ImplicitParams #-} class C a where toInt :: a -> Int instance (?imp :: Int) => C [a] where toInt _ = ?imp test :: Int test = let ?imp = 5 in toInt "Hello, world" }}} test evaluates to 5. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8912> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #9344: takeWhile does not participate in list fusion
by GHC 21 Aug '14

21 Aug '14

#9344: takeWhile does not participate in list fusion -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.8.3 Keywords: | Differential Revisions: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- `takeWhile` doesn't do the list fusion thing. This alternative definition seems to fix that, at least to a great extent. It fused completely in a simple test, and incompletely but still usefully in a more complex one. I don't know how to write the appropriate translate/untranslate RULES for it yet. {{{ #!haskell {-# LANGUAGE ScopedTypeVariables #-} takeWhileFB :: forall a . (a -> Bool) -> [a] -> [a] takeWhileFB p xs = build tw' where tw' :: forall b . (a -> b -> b) -> b -> b tw' kons knil = foldr go knil xs where go x rest | p x = x `kons` rest | otherwise = knil }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9344> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #9140: Unboxed tuples fails in GHCi (7.8.2)
by GHC 20 Aug '14

20 Aug '14

#9140: Unboxed tuples fails in GHCi (7.8.2) ------------------------------------+------------------------------------- Reporter: osa1 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: GHCi crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Creating an unboxed tuple in GHCi causes panic: {{{ ➜ ~ ghci -XUnboxedTuples GHCi, version 7.8.2: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. ghci> let a = (# 1 #) ghc: panic! (the 'impossible' happened) (GHC version 7.8.2 for x86_64-unknown-linux): dsLet: unlifted AbsBinds [a{tv auv} [tv]] [$dNum_auw{v} [lid]] {Exports: [a{v asV} [lid] <= a{v asY} [lid] /\(@ a{tv auy} [tv]). \($dNum_auz{v} [lid] :: base:GHC.Num.Num{tc 2b} a{tv auy} [tv]). let {EvBinds{$dNum_auC{v} [lid] = $dNum_auz{v} [lid]}} (<>) @ a{tv auy} [tv] $dNum_auC{v} [lid]] Exported types: a{v asV} [lid] :: forall a{tv auv} [tv]. base:GHC.Num.Num{tc 2b} a{tv auv} [tv] => (# a{tv auv} [tv] #) [LclId, Str=DmdType] Binds: {<interactive>:2:5-15} a{v asY} [lid] :: (# a{tv auv} [tv] #) [LclId, Str=DmdType] a{v asY} = {<interactive>:2:9-15} (# 1 ((base:GHC.Num.fromInteger{v 02A}) @ a{tv auv} [tv] $dNum_au8{v} [lid] 1) #) <> Evidence: EvBinds{$dNum_au8{v} [lid] = $dNum_auw{v} [lid]}} base:GHC.Base.returnIO{v 0z} [gid] @ [()] (ghc-prim:GHC.Types.:{(w) v 65} [gid[DataCon]] @ () (ghc-prim:GHC.Prim.unsafeCoerce#{(w) v 0u} [gid] @ (forall a{tv auv} [tv]. base:GHC.Num.Num{tc 2b} a{tv auv} [tv] => (# a{tv auv} [tv] #)) @ () a{v asV} [lid]) (ghc-prim:GHC.Types.[]{(w) v 6n} [gid[DataCon]] @ ())) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug ghci> let a = (# 1, 2 #) ghc: panic! (the 'impossible' happened) (GHC version 7.8.2 for x86_64-unknown-linux): dsLet: unlifted AbsBinds [a{tv auW} [tv], a{tv auX} [tv]] [$dNum_auY{v} [lid], $dNum_auZ{v} [lid]] {Exports: [a{v auK} [lid] <= a{v auN} [lid] /\(@ a{tv av1} [tv]). /\(@ a{tv av2} [tv]). \($dNum_av3{v} [lid] :: base:GHC.Num.Num{tc 2b} a{tv av2} [tv]). \($dNum_av4{v} [lid] :: base:GHC.Num.Num{tc 2b} a{tv av1} [tv]). let {EvBinds{$dNum_av8{v} [lid] = $dNum_av3{v} [lid] $dNum_av9{v} [lid] = $dNum_av4{v} [lid]}} (<>) @ a{tv av1} [tv] @ a{tv av2} [tv] $dNum_av8{v} [lid] $dNum_av9{v} [lid]] Exported types: a{v auK} [lid] :: forall a{tv auW} [tv] a{tv auX} [tv]. (base:GHC.Num.Num{tc 2b} a{tv auX} [tv], base:GHC.Num.Num{tc 2b} a{tv auW} [tv]) => (# a{tv auW} [tv], a{tv auX} [tv] #) [LclId, Str=DmdType] Binds: {<interactive>:3:5-18} a{v auN} [lid] :: (# a{tv auW} [tv], a{tv auX} [tv] #) [LclId, Str=DmdType] a{v auN} = {<interactive>:3:9-18} (# 1 ((base:GHC.Num.fromInteger{v 02A}) @ a{tv auW} [tv] $dNum_auR{v} [lid] 1), 2 ((base:GHC.Num.fromInteger{v 02A}) @ a{tv auX} [tv] $dNum_auT{v} [lid] 2) #) <> Evidence: EvBinds{$dNum_auR{v} [lid] = $dNum_auZ{v} [lid] $dNum_auT{v} [lid] = $dNum_auY{v} [lid]}} base:GHC.Base.returnIO{v 0z} [gid] @ [()] (ghc-prim:GHC.Types.:{(w) v 65} [gid[DataCon]] @ () (ghc-prim:GHC.Prim.unsafeCoerce#{(w) v 0u} [gid] @ (forall a{tv auW} [tv] a{tv auX} [tv]. (base:GHC.Num.Num{tc 2b} a{tv auX} [tv], base:GHC.Num.Num{tc 2b} a{tv auW} [tv]) => (# a{tv auW} [tv], a{tv auX} [tv] #)) @ () a{v auK} [lid]) (ghc-prim:GHC.Types.[]{(w) v 6n} [gid[DataCon]] @ ())) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug ghci> }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9140> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #8712: Data.Ix missing info on row/column major indexing
by GHC 19 Aug '14

19 Aug '14

#8712: Data.Ix missing info on row/column major indexing -------------------------------------+------------------------------------- Reporter: mirpa | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.6.3 Keywords: row, column, | Operating System: Unknown/Multiple major, Ix | Type of failure: Documentation Architecture: Unknown/Multiple | bug Difficulty: Easy (less than 1 | Test Case: hour) | Blocking: Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- I've tried to use {{{Data.Ix}}} with {{{Data.Vector}}} for image manipulations and I confused column with row-major indexing. I expected than {{{Data.Ix.index ((0,0),(3,3)) (1,0) == 1}}} while it is actually equal to 4. Documentation for {{{Data.Ix}}} should explicitly state that it is row- major indexing and function {{{Data.Ix.index}}} might be accompanied by example like: {{{index ((0,0),(3,3)) (1,0) == 4}}} which should be obvious. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8712> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #8621: Pull request for inclusion in `unix' module of fsync(2), fdatasync(2), posix_fadvise(2) and posix_fallocate(2)
by GHC 19 Aug '14

19 Aug '14

#8621: Pull request for inclusion in `unix' module of fsync(2), fdatasync(2), posix_fadvise(2) and posix_fallocate(2) -------------------------------------------+------------------------------- Reporter: jimenezrick | Owner: Type: task | Status: new Priority: normal | Milestone: 7.8.1 Component: libraries/unix | Version: 7.6.3 Keywords: | Operating System: POSIX Architecture: Unknown/Multiple | Type of failure: Difficulty: Easy (less than 1 hour) | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: -------------------------------------------+------------------------------- Discussion in the mailing list (I fixed both commented silly issues): http://www.haskell.org/pipermail/libraries/2013-December/021756.html Please review this pull request: https://github.com/jimenezrick/unix/compare/master...file-utils.patch If you find interesting this patch, then: git pull https://github.com/jimenezrick/unix.git file-utils -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8621> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #9154: Links to Cabal documentation from the user guide are broken
by GHC 19 Aug '14

19 Aug '14

#9154: Links to Cabal documentation from the user guide are broken ------------------------------------+------------------------------------- Reporter: etrepum | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- At http://www.haskell.org/ghc/docs/7.8.2/html/users_guide/packages.html there are two broken links to Cabal documentation, there's also a broken absolute link to the same place from the haddock documentation. {{{ $ find ./share/doc/ghc -name "*.html" -exec grep -H "Cabal/index.html" {} \; ./share/doc/ghc/html/haddock/invoking.html: tool <a class="ulink" href="http://www.haskell.org/ghc/docs/latest/html/Cabal/index.html" target="_top">Cabal</a> ./share/doc/ghc/html/users_guide/packages.html: <a class="ulink" href="../Cabal/index.html" target="_top">Cabal documentation</a> ./share/doc/ghc/html/users_guide/packages.html: <a class="ulink" href="../Cabal/index.html" target="_top">Cabal</a> infrastructure }}} I suppose the right place for all of these links is probably http://www.haskell.org/cabal/users-guide/ ? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9154> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #8943: Add System.Process.createPipe
by GHC 19 Aug '14

19 Aug '14

#8943: Add System.Process.createPipe -------------------------------------+------------------------------------- Reporter: tibbe | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: libraries/process | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- As agreed in: http://comments.gmane.org/gmane.comp.lang.haskell.libraries/21373 I've validated the patch on OS X, but I need someone to validate on Windows. I originally wrote this code for cabal and tested it on all platforms back then. I no longer have a Windows machine and the imports in `System.Process` are messy enough that someone needs to check that it still builds on Windows. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8943> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #9335: Add Functor, Applicative, Monad instances for First, Last
by GHC 19 Aug '14

19 Aug '14

#9335: Add Functor, Applicative, Monad instances for First, Last -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Differential Revisions: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: -------------------------------------+------------------------------------- This was proposed in 2011 [1] with no serious objections although wasn't implemented until it was again mentioned in 2014 [2]. [1] http://www.haskell.org/pipermail/libraries/2011-January/015552.html [2] http://www.haskell.org/pipermail/libraries/2014-June/023228.html -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9335> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #9382: Have rts/Linker.c lookupSymbol find symbols in the process executable.
by GHC 19 Aug '14

19 Aug '14

#9382: Have rts/Linker.c lookupSymbol find symbols in the process executable. -------------------------------------+------------------------------------- Reporter: facundo.dominguez | Owner: Type: bug | facundo.dominguez Priority: normal | Status: new Component: Compiler | Milestone: Keywords: | Version: Architecture: Unknown/Multiple | Operating System: Windows Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: #9381 #7015 | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- In windows, the function `lookupSymbol` in `Linker.c` does not look for symbols exported in the executable. Thus, when a program is linked with `-optl -export-all-symbols`, the function `lookupSymbol` still fails to find them. Fixing this would improve the usability of `-rdynamic` (#9381) and an upcoming implementation for #7015. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9382> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #9150: libraries/time: parseTime barfs on leading space in format string
by GHC 18 Aug '14

18 Aug '14

#9150: libraries/time: parseTime barfs on leading space in format string --------------------------+------------------------------------------------ Reporter: mjo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.8.2 libraries (other) | Operating System: Unknown/Multiple Keywords: | Type of failure: Incorrect result at runtime Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: | Unknown | Blocked By: | Related Tickets: | --------------------------+------------------------------------------------ This used to work around 1.4.0, one of my test suites caught it: {{{ module Main where import Data.Time.Clock import Data.Time.Format import System.Locale main :: IO () main = do putStrLn "Trailing space is handled:" print $ (parseTime defaultTimeLocale "%M " "15 " :: Maybe UTCTime) putStrLn "\nBut leading space isn't:" print $ (parseTime defaultTimeLocale " %M" " 15" :: Maybe UTCTime) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9150> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5