January 2015 - ghc-tickets

Re: [GHC] #7298: Test 2228 fails with dynamic-by-default
by GHC 19 Jan '15

19 Jan '15

#7298: Test 2228 fails with dynamic-by-default -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.10.1 Component: GHCi | Version: 7.6.1 Resolution: wontfix | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * cc: hvr (added) * status: new => closed * resolution: => wontfix Comment: Closing, since we're moving away from dynamic by default anyway. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7298#comment:4> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9957: Document -fwarn-unticked-promoted-constructors in release notes
by GHC 19 Jan '15

19 Jan '15

#9957: Document -fwarn-unticked-promoted-constructors in release notes -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: | Version: 7.10.1-rc1 Documentation | Operating System: Unknown/Multiple Keywords: | Type of failure: Documentation Architecture: | bug Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The new flag `-fwarn-unticked-promoted-constructors` should be documented in the release notes, as users upgrading to 7.10 may need to update their code or flags to continue compiling with `-Wall -Werror`. Perhaps it should even be removed from `-Wall` (c.f. [https://www.haskell.org/pipermail/ghc-devs/2014-December/007738.html discussion here])? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9957> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #9922: Partial type signatures + extensions panic
by GHC 19 Jan '15

19 Jan '15

#9922: Partial type signatures + extensions panic -------------------------------------+------------------------------------- Reporter: monoidal | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.9 checker) | Operating System: Keywords: | Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Compile- Difficulty: Unknown | time crash Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Partial type signatures combined with the following GHC extensions cause a panic: {{{#!hs class C a where default f :: _ -- DefaultSignatures instance Num Bool where negate :: _ -- InstanceSigs deriving instance _ -- StandaloneDeriving }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9922> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #8624: -ddump-splices-file
by GHC 19 Jan '15

19 Jan '15

#8624: -ddump-splices-file ------------------------------------+------------------------------------- Reporter: GregWeber | Owner: Type: feature request | 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: | ------------------------------------+------------------------------------- I am proposing an additional feature, `-ddump-splices-file` that generates a corresponding `.hs.th` file for every `.hs` file that uses Template Haskell. `-ddump-splices` is an invaluable but a frustrating way to look at generated Haskell code. If TH generation were some kind of error message, the current output would make sense. However, TH is generating code that we rely on and would be easier to comprehend if we could see it in a way the most similar to our existing Haskell code. There is a valid complaint that when TH defines something you can't just grep for it, you have to know what TH is defining by reading documentation and imagining something that isn't in front of you. If you have a file `Foo.hs` `-ddump-splices-file` will generate `Foo.hs.th`. Then whenever someone greps after buliding they will find the declaration. If you check these files in they can grep even before building. Similarly, an IDE can show these files as the source of a declaration. Also, if the TH generation changes in some way when a TH function changes, that will be visible. This seems like a relatively easy feature to add. Any pointers on where to get started? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8624> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 26

[GHC] #9384: setNumCapabilities call breaks eventlog events
by GHC 19 Jan '15

19 Jan '15

#9384: setNumCapabilities call breaks eventlog events -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Profiling | Version: 7.8.3 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: Incorrect Difficulty: Unknown | result at runtime Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- The problem was found when i tried to eventlog '''ghc --make''' itself. I've missinterpreted is as a threadscope bug: https://github.com/haskell/ThreadScope/issues/37 Here is small program to reliably reproduce the bug: {{{#!hs module Main where import qualified Data.List as L import qualified System.Environment as E import Control.Monad import qualified Control.Concurrent as CC import qualified Control.Concurrent.MVar as CC slow_and_silly :: Int -> IO Int slow_and_silly i = return $ length $ L.foldl' (\a v -> a ++ [v]) [] [1..i] -- build as: -- $ ghc --make a -O2 -threaded -eventlog -- valid eventlog: -- $ ./a 2 7000 +RTS -ls -N2 -- $ ghc-events validate threads a.eventlog -- Valid eventlog: -- ... -- invalid eventlog -- $ ./a 2 7000 +RTS -ls -- $ ghc-events validate threads a.eventlog -- Invalid eventlog: -- ... main = do [caps, count] <- E.getArgs let n_caps :: Int n_caps = read caps max_n :: Int max_n = read count CC.setNumCapabilities n_caps waits <- replicateM n_caps $ CC.newEmptyMVar forM_ waits $ \w -> CC.forkIO $ do slow_and_silly max_n >>= print CC.putMVar w () forM_ waits $ \w -> CC.takeMVar w }}} How to reproduce (comments have '''ghc-events''' version): {{{ $ ghc --make a -O2 -threaded -eventlog $ ./a 2 7000 +RTS -ls -N2 $ threadscope a.eventlog # works $ ./a 2 7000 +RTS -ls $ threadscope a.eventlog # crashes }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9384> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #9889: Pattern synonym does not work at top level
by GHC 19 Jan '15

19 Jan '15

#9889: Pattern synonym does not work at top level -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: PatternSynonyms | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- When I say {{{ pattern Id x = x Id x = True }}} I get {{{ Not in scope: data constructor ‘Id’ }}} This happens with both 7.8.3 and HEAD. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9889> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #10002: Invalid ghcversion.h file in GHC 7.10.1 RC1
by GHC 19 Jan '15

19 Jan '15

#10002: Invalid ghcversion.h file in GHC 7.10.1 RC1 -------------------------------------+------------------------------------- Reporter: asr | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.10.1-rc1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Using cpphs 1.18.7, I got the following error with GHC 7.10.1 RC1: {{{ $ cat Main.hs {-# LANGUAGE CPP #-} module Main where main :: IO () main = putStrLn "Hello, World!" }}} {{{ $ ghc -pgmP cpphs -optP --cpp Main.hs ... /usr/local/stow/ghc-7.10.1.RC1/lib/ghc-7.10.0.20141222/include/ghcversion.h:12:30: parse error on input ‘\\’ }}} By replacing {{{\\}}} by {{{\}}} in ghcversion.h, the issue is fixed. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10002> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #9992: Constructor specialization requires eta expansion
by GHC 19 Jan '15

19 Jan '15

#9992: Constructor specialization requires eta expansion -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Keywords: | Operating System: Unknown/Multiple performance | Type of failure: Runtime Architecture: | performance bug Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- I recently encountered a slightly tricky performance issue[1] in `bytestring`'s `Builder` implementation which required explicit eta expansion in order for GHC to perform ConstrSpec. We have {{{#!hs data BufferRange = BufferRange {-# UNPACK #-} !(Ptr Word8) -- First byte of range {-# UNPACK #-} !(Ptr Word8) -- First byte /after/ range data BuildSignal a = ... -- Just a vanilla ADT type BuildStep a = BufferRange -> IO (BuildSignal a) }}} We end up with Core (full version https://gist.github.com/bgamari/091e3dac9c45ee9accf1#file-slow-hs-L1) that looks like this, {{{#!hs Main.$wa :: GHC.Prim.Word# -> GHC.Prim.Int# -> forall r_aKUt. Data.ByteString.Builder.Internal.BuildStep r_aKUt -> Data.ByteString.Builder.Internal.BuildStep r_aKUt Main.$wa = \ (ww_s10YU :: GHC.Prim.Word#) (ww1_s10YY :: GHC.Prim.Int#) (@ r_aKUt) (w_s10YR :: Data.ByteString.Builder.Internal.BuildStep r_aKUt) -> case ww1_s10YY of wild_XE { __DEFAULT -> ( \ (eta1_X1Q :: Data.ByteString.Builder.Internal.BufferRange) -> case eta1_X1Q of BufferRange a b -> -- A bunch of code eventually ending in a recursive call to $wa ) 0 -> w_s10YR } }}} If `w_s10YR` is eta-expanded GHC will run ConstrSpec, eliminating the fields of `BufferRange` to be unpacked between iterations of `$wa` and substantially improving performance. In [1] we had to manually eta-expand the empty case to ensure that this would happen. It would be great if GHC would identify cases like this. [1] https://github.com/haskell/bytestring/pull/40 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9992> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #7870: Compilation errors break the complexity encapsulation on DSLs, impairs success in industry
by GHC 17 Jan '15

17 Jan '15

#7870: Compilation errors break the complexity encapsulation on DSLs, impairs success in industry -------------------------------------+------------------------------------- Reporter: agocorona | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.7 checker) | Keywords: DSL, Resolution: | Error, Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by snoyberg): * cc: snoyberg (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7870#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10000: Derived DataKinds Typeable instance collision leads to SafeHaskell violation
by GHC 17 Jan '15

17 Jan '15

#10000: Derived DataKinds Typeable instance collision leads to SafeHaskell violation -------------------------------------+------------------------------------- Reporter: shachaf | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The derived `Typeable` instances for a kind (with `DataKinds`) is equal to the instance of a type with the same name: {{{ λ> data T = T λ> typeRep (Proxy :: Proxy T) == typeRep (Proxy :: Proxy 'T) True }}} This can be used to violate `SafeHaskell` easily: {{{#!hs {-# LANGUAGE AutoDeriveTypeable, DataKinds, TypeFamilies, RankNTypes #-} module Unsafe where import Data.Typeable data T = T data family F p newtype instance F (Proxy T) = ID (forall a. a -> a) newtype instance F (Proxy 'T) = UC (forall a b. a -> b) uc :: a -> b uc = case cast (ID id) of Just (UC f) -> f }}} {{{ $ ghc -XSafe Unsafe.hs -e "uc 'a' :: Int" 97 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10000> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4