December 2014 - ghc-tickets

[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] #9900: Support pattern synonyms in GHCi
by GHC 09 Jan '15

09 Jan '15

#9900: Support pattern synonyms in GHCi -------------------------------------+------------------------------------- Reporter: cactus | Owner: cactus Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: GHCi | Version: 7.8.3 Keywords: PatternSynonyms | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: 8749, 7253 | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Pattern synonyms are not parsed in GHCi: {{{ λ» :set -XPatternSynonyms λ» pattern P x = x <interactive>:5:1: parse error on input ‘pattern’ }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9900> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15

[GHC] #9875: ld -l:filename.dylib does not appear to be portable
by GHC 09 Jan '15

09 Jan '15

#9875: ld -l:filename.dylib does not appear to be portable ------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: GHCi | Version: 7.9 Keywords: | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: GHCi crash Difficulty: Unknown | Test Case: T2276_ghci Blocked By: | Blocking: Related Tickets: | Differential Revisions: ------------------------------------+------------------------------------- In GHCi, we seem to use `-l:` to ask the linker to link a specific filename, instead of munging the filename. Unfortunately, this does not appear to be universally supported by all versions of `ld`. Here is the manpage `ld` that comes with Mac OS X 10.10.1: {{{ Options that control libraries -lx This option tells the linker to search for libx.dylib or libx.a in the library search path. If string x is of the form y.o, then that file is searched for in the same places, but without prepending `lib' or appending `.a' or `.dylib' to the filename. }}} It causes T2276_ghci to fail: {{{ --- /dev/null 2014-12-09 20:57:29.000000000 -0500 +++ ./T2276_ghci.run.stderr 2014-12-09 20:57:30.000000000 -0500 @@ -0,0 +1,3 @@ +ld: library not found for -l:ghc75404_1.dylib +clang: error: linker command failed with exit code 1 (use -v to see invocation) +phase `Linker' failed (exitcode = 1) *** unexpected failure for T2276_ghci(ghci }}} Regression seems to have been introduced by: {{{ commit 383733b9191a36e2d3f757700842dbc3855911d9 Author: Peter Trommler <ptrommler(a)acm.org> Date: Sun Nov 30 12:00:39 2014 -0600 Fix obscure problem with using the system linker (#8935) }}} Probably we can fix it by not using colon and making sure the libraries we generate have the right file format. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9875> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #9934: Typo in GHC.RTS.Flags
by GHC 09 Jan '15

09 Jan '15

#9934: Typo in GHC.RTS.Flags -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.10.1-rc1 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 | Type of failure: Other hour) | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Currently, the {{{GCFlags}}} data type in the {{{GHC.RTS.Flags}}} module of {{{base-4.8.0.0}}} has a field named {{{heapSizeSuggesionAuto}}} (without a {{{t}}} in {{{Suggesion}}}). Given that the corresponding struct field in {{{rts/Flags.h}}} is named {{{heapSizeSuggestionAuto}}}, this is probably a typo. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9934> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #9904: ghc: out of memory, requested 1048576 bytes on openbsd
by GHC 09 Jan '15

09 Jan '15

#9904: ghc: out of memory, requested 1048576 bytes on openbsd ------------------------------------+---------------------------------- Reporter: vu3rdd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: cabal-install | Operating System: OpenBSD Architecture: Unknown/Multiple | Type of failure: Other Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ------------------------------------+---------------------------------- Hi, I freshly installed OpenBSD 5.6 on an AMD64 system. I also installed ghc and cabal-install from the OpenBSD package system. The version in OpenBSD 5.6 package tree is: $ ghc --version The Glorious Glasgow Haskell Compilation System, version 7.6.3 $ cabal --version cabal-install version 1.16.0.2 using version 1.16.0 of the Cabal library Now, I do a `cabal update' and `cabal install cabal-install'. I get this error: ghc: out of memory, requested 1048576 bytes I am not sure if it is a cabal-install bug or a ghc bug or an OpenBSD bug. So, if you think it is not a ghc bug, please go ahead and close this bug (and accept my apologies..), I will open it against cabal-install or openbsd instead. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9904> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #8486: cannot derive new-typeable instances for promoted data types taking parameters
by GHC 07 Jan '15

07 Jan '15

#8486: cannot derive new-typeable instances for promoted data types taking parameters ------------------------------------+------------------------------------- Reporter: aavogt | 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: | ------------------------------------+------------------------------------- Hi, The following code shows the issue: {{{ {-# LANGUAGE DataKinds, DeriveDataTypeable, KindSignatures, PolyKinds, StandaloneDeriving #-} import Data.Typeable import GHC.TypeLits data T (a :: [*]) = T deriving (Typeable) t = T :: T [Int, Double] deriving instance Typeable '[] {- *Main> typeOf t <interactive>:24:1: No instance for (Typeable (* -> [*] -> [*]) ((':) *)) arising from a use of ‛typeOf’ In the expression: typeOf t In an equation for ‛it’: it = typeOf t -} }}} ghc7.7-20131004 doesn't allow either of the following: {{{ deriving instance (Typeable a, Typeable b) => Typeable (a ': b) -- or deriving instance Typeable (':) }}} On ghc-7.6 I could write my own `instance Typeable (T a)`, but this has been disabled it seems. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8486> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #9111: base should export Typeable instances of its promoted data constructors
by GHC 07 Jan '15

07 Jan '15

#9111: base should export Typeable instances of its promoted data constructors ------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | 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: | ------------------------------------+------------------------------------- As initially reported in #8486, `base` does not export `Typeable` instances for its promoted data constructors, as witnessed by this: {{{ {-# LANGUAGE DataKinds #-} import Data.Typeable x = typeRep (Proxy :: Proxy True) }}} yields {{{ No instance for (Typeable 'True) arising from a use of ‘typeRep’ In the expression: typeRep (Proxy :: Proxy True) In an equation for ‘x’: x = typeRep (Proxy :: Proxy True) }}} It is indeed possible to derive these instances locally with standalone deriving, but that seems very problematic, should multiple modules do that independently. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9111> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 24