December 2013 - ghc-tickets

[GHC] #8602: Wrong argument order to Haskell pre-processor (-F, -pgmF, -optF)
by GHC 07 Jan '14

07 Jan '14

#8602: Wrong argument order to Haskell pre-processor (-F, -pgmF, -optF) -----------------------------------+--------------------------------------- Reporter: SimonHengel | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time crash Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -----------------------------------+--------------------------------------- So far, and that is what is documented > Additional arguments to the pre-processor can be passed in using the {{{-optF}}} option. These are fed to cmd on the command line after the three standard input and output arguments. However, {{{GHC 7.7.20131026}}} passes additional arguments (specified with {{{-optF}}}) before the three standard arguments. Steps to reproduce: {{{ $ echo '{-# OPTIONS_GHC -F -pgmF ./foo.sh -optF bar #-}' > Foo.hs $ echo 'echo $*' > foo.sh $ chmod +x foo.sh $ ghci Foo.hs }}} Expected result: {{{Foo.hs Foo.hs /tmp/ghc16665_0/ghc16665_1.hspp bar}}} is printed to stdout Actual result: {{{bar Foo.hs Foo.hs /tmp/ghc16665_0/ghc16665_1.hspp}}} is printed to stdout -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8602> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #8502: Document a surprising {{{unsafeDupablePerformIO}}} limitation.
by GHC 07 Jan '14

07 Jan '14

#8502: Document a surprising {{{unsafeDupablePerformIO}}} limitation. -------------------------------------+------------------------------------- Reporter: int-e | Owner: Type: task | Status: new Priority: normal | Milestone: 7.8.1 Component: libraries/base | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Documentation Difficulty: Easy (less than 1 | bug hour) | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- We just discussed the following code on #ghc. {{{ import System.IO.Unsafe import Control.Concurrent.MVar import Control.Concurrent import GHC.Conc (par, pseq) x :: MVar Int -> Int -> Int x m a = unsafeDupablePerformIO $ withMVar m $ \i -> do sum [1..1000000 + a] `seq` return i main1 = do m <- newMVar 42 let w = x m 0 w `par` print w {- spark: thread blocked indefinitely in an MVar operation -} main2 = do m <- newMVar 42 let w = x m 0 forkIO $ print w forkIO $ print w print w {- spark: <<loop>> spark: <<loop>> -} main = main2 }}} This is not a bug; what happens is that the RTS suspends one of the duplicated computations of {{{w}}}, effectively killing the IO action that was passed to {{{unsafeDupablePerformIO}}} in the middle. This limitation of {{{unsafeDupablePerformIO}}} should be documented. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8502> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #8638: Optimize by demoting "denormalized" Integers (i.e. J# -> S#)
by GHC 04 Jan '14

04 Jan '14

#8638: Optimize by demoting "denormalized" Integers (i.e. J# -> S#) ------------------------------+-------------------------------------------- Reporter: hvr | Owner: hvr Type: feature | Status: new request | Milestone: 7.8.1 Priority: normal | Version: 7.7 Component: libraries | Operating System: Unknown/Multiple (other) | Type of failure: Runtime performance bug Keywords: integer- | Test Case: gmp | Blocking: Architecture: | Unknown/Multiple | Difficulty: Unknown | Blocked By: | Related Tickets: | ------------------------------+-------------------------------------------- In the course of a recent [discussion on reddit](http://www.reddit.com/r/haskell/comments/1twtvm/the_problem_with_in… it was highlighted, that `integer-gmp` doesn't try to demote `J#` to the more efficient `S#` if even though they would fit. The attached proof-of-concept patch introduces a "smart" `J#` constructor which constructs a `S#` instead if possible: {{{ #!hs -- | Demote 'J#' to 'S#' if possible. See also 'smartJ#'. toSmall :: Integer -> Integer toSmall i@(S# _) = i toSmall (J# 0# _) = S# 0# toSmall (J# 1# mb#) | isTrue# (v ># 0#) = S# v where v = indexIntArray# mb# 0# toSmall (J# -1# mb#) | isTrue# (v <# 0#) = S# v where v = negateInt# (indexIntArray# mb# 0#) toSmall i = i -- | Smart 'J#' constructor which tries to construct 'S#' if possible smartJ# :: Int# -> ByteArray# -> Integer smartJ# s# mb# = toSmall (J# s# mb#) }}} And replaces a couple of `J#`-constructions which are likely to produce a `S#`-fitting `Integer`. A `nofib` comparison for vanilla GHC HEAD vs patched GHC HEAD is attached for further discussion. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8638> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #8643: Silent name shadowing
by GHC 03 Jan '14

03 Jan '14

#8643: Silent name shadowing ------------------------------------+------------------------------------- Reporter: mirpa | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.4.1 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #5288 | ------------------------------------+------------------------------------- I have code like: {{{ let baseTex = (getTexPropNode nodes . NC.properties . NC.av $ geometry) >>= baseTex >>= (flip Map.lookup texs) . NC.tdSource }}} which gives me error: {{{ Games/secunda/Graph.hs:224:23: Couldn't match expected type `TexProperty -> Maybe a0' with actual type `Maybe b0' In the second argument of `(>>=)', namely `baseTex' In the first argument of `(>>=)', namely `(getTexPropNode nodes . NC.properties . NC.av $ geometry) >>= baseTex' In the expression: (getTexPropNode nodes . NC.properties . NC.av $ geometry) >>= baseTex >>= (flip Map.lookup texs) . NC.tdSource }}} However if I try to get type of expressin on the right hand side of {{{let baseTex = ...}}} in ghci then I get no error. Problem is that I am importing module with function {{{baseTex :: TexProperty -> Maybe TexDesc}}} and that function is shadowed by {{{let}}} expression which should have type of {{{Maybe Texture}}}. I tried to use {{{ghc-options: -Wall -fwarn-name-shadowing}}} in Cabal with no effect. From above error I conclude, that I made a type error. So I try to get type of expression in ghci which results in correct type - that makes my confusion. While I am trying to concentrate on type error, I am missing that I shadowed function by variable. This is not for the first time I've done same mistake. I would appreciate to get warnings about name shadowing since they makes me belief that I am using names of different type. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8643> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #8579: Loading a module in GHCi affects shadowing
by GHC 03 Jan '14

03 Jan '14

#8579: Loading a module in GHCi affects shadowing ------------------------------------+------------------------------------- Reporter: monoidal | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | 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: | ------------------------------------+------------------------------------- In GHCi we can redefine a data declaration; last definition counts. But loading a module has a side effect of bringing the first declaration to front: {{{ λ> data A = X λ> data A = Y λ> :i A data A = Y -- Defined at <interactive>:3:6 λ> :m Data.List λ> :i A data A = X -- Defined at <interactive>:2:6 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8579> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #8625: GHCi does not support some TH elements, while those elemenst are working in hs files
by GHC 03 Jan '14

03 Jan '14

#8625: GHCi does not support some TH elements, while those elemenst are working in hs files ------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Hello. Below is a code, which works when using runhaskell, but does not work in GHCi. In GHCi we get following error: runQ [d| instance ( y ~ (t->t) ) => Member Vector y where member v = test |] <interactive>:19:6: Exotic predicate type not (yet) handled by Template Haskell y ~ (t -> t) code: {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE UndecidableInstances #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE TemplateHaskell #-} module Main where import Language.Haskell.TH class a ~ b => HEq a b test :: a -> a test x = x data Vector class Member a b where member :: a -> b main :: IO () main = print =<< runQ [d| instance y ~ (t->t) => Member Vector y where member v = test |] -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8625> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #8639: GHC API `runStmt` overrides qualified import of `it` variable
by GHC 03 Jan '14

03 Jan '14

#8639: GHC API `runStmt` overrides qualified import of `it` variable ------------------------------------+------------------------------------- Reporter: agibiansky | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | 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: | ------------------------------------+------------------------------------- The `runStmt` function in `InteractiveEval` creates an `it` variable storing the last result. However, this variable somehow shadows qualified variables with the name `it`. For instance, importing Test.Hspec, running any statement, and then trying to use Test.Hspec.it (qualified) results in an "out of scope" error. The following small program demonstrates this: {{{ import GHC import GhcMonad import Outputable import GHC.Paths main = runGhc (Just libdir) $ do flags <- getSessionDynFlags setSessionDynFlags (flags{ hscTarget = HscInterpreted, ghcLink = LinkInMemory}) imps <- mapM parseImportDecl ["import Prelude", "import Test.Hspec"] setContext (map IIDecl imps) -- With the next line, you get an "Not in scope" exception. -- If you comment out this runStmt, it runs without error and prints the type. runStmt "3" RunToCompletion exprType "Test.Hspec.it" >>= (liftIO . putStrLn . showPpr flags) }}} GHCi somehow avoids this, but I have no idea how and could not figure it out from the sources. What's going on? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8639> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #8640: :show imports ignores -XNoImplicitPrelude
by GHC 03 Jan '14

03 Jan '14

#8640: :show imports ignores -XNoImplicitPrelude ------------------------------------+------------------------------------- Reporter: monoidal | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | 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: | ------------------------------------+------------------------------------- The implicit import should not be shown: {{{ $ ghci -XNoImplicitPrelude ... > :show imports import Prelude -- implicit }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8640> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #8636: Infix declaration on operators ending on backslash
by GHC 02 Jan '14

02 Jan '14

#8636: Infix declaration on operators ending on backslash ----------------------------+---------------------------------------------- Reporter: | Owner: jcristovao | Status: new Type: bug | Milestone: Priority: normal | Version: 7.7 Component: Compiler | Operating System: Linux Keywords: | Type of failure: GHC rejects valid program Architecture: x86_64 | Test Case: (amd64) | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: | ----------------------------+---------------------------------------------- Hi, I was trying the latest GHC Head (version 7.7.20131227), when I noticed a regression. I don't know if this is intended behaviour or not. This compiled ok under 7.6.3 {{{ (?&&\) :: (Monoid a) => a -> (a -> Bool) -> a (?&&\) value f = if f value then value else mempty infixl 1 ?&&\ }}} Under 7.7, the infixl declaration only works if I double escape it. {{{ infixl 1 ?&&\\ }}} Is this intended? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8636> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #8606: Fix whitespaces in rts/sm/Scav.c
by GHC 02 Jan '14

02 Jan '14

#8606: Fix whitespaces in rts/sm/Scav.c ------------------------------------+------------------------------------- Reporter: Tarrasch | Owner: simonmar Type: task | Status: new Priority: lowest | Milestone: Component: Runtime System | 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: | ------------------------------------+------------------------------------- -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8606> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2