December 2013 - ghc-tickets

[GHC] #8451: Link problem on FreeBSD
by GHC 18 Jan '14

18 Jan '14

#8451: Link problem on FreeBSD ------------------------------+-------------------------------------------- Reporter: kazu- | Owner: yamamoto | Status: new Type: bug | Milestone: Priority: high | Version: 7.7 Component: Compiler | Operating System: FreeBSD Keywords: | Type of failure: GHC doesn't work at all Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: | ------------------------------+-------------------------------------------- GHC head on FreeBSD causes a link error if -prof and -threaded are specified: {{{ % cat main.hs main = putStrLn "hello" % ghc -prof -threaded main.hs [1 of 1] Compiling Main ( main.hs, main.o ) /usr/local/lib/gcc47/gcc/x86_64-portbld- freebsd9.1/4.7.3/../../../../../x86_64-portbld-freebsd9.1/bin/ld: cannot find -lthr collect2: error: ld returned 1 exit status }}} Note that libHSrts_thr* are certainly installed. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8451> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #8628: dynCompileExpr breaks repeated runDecls of the same name
by GHC 17 Jan '14

17 Jan '14

#8628: dynCompileExpr breaks repeated runDecls of the same name ------------------------------------+------------------------------------- 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: | ------------------------------------+------------------------------------- Using `dynCompileExpr` with `runDecls` from `InteractiveEval` seems to be incredibly problematic when evaluating declarations for the same name. For instance, consider the following code: {{{ runDecls "data X = Y Int" gtry $ runStmt "print (Y 3)" RunToCompletion :: GhcMonad m => m (Either SomeException RunResult) runDecls "data X = Y Int deriving Show" runStmt "print (Y 8)" RunToCompletion }}} As expected, this prints `Y 8` once (the first one fails because `X` is not an instance of `Show`). However, if we insert an arbitrary `dynCompileExpr`, things begin to break: {{{ runDecls "data X = Y Int" gtry $ runStmt "print (Y 3)" RunToCompletion :: GhcMonad m => m (Either SomeException RunResult) runDecls "data X = Y Int deriving Show" _ <- dynCompileExpr "'x'" runStmt "print (Y 8)" RunToCompletion }}} We then get: {{{ No instance for (GHC.Show.Show :Interactive.X) arising from a use of `System.IO.print' Possible fix: add an instance declaration for (GHC.Show.Show :Interactive.X) }}} Which is clearly incorrect - we haven't done anything to change the data declaration. I'm not sure what's going on, but I've tried to investigate into the source of `dynCompileExpr`. It loads `Data.Dynamic` via a `setContext` and then unloads it, and that may be the issue. If we do the following (very similar to the `dynCompileExpr` source), things work fine: {{{ runDecls "data X = Y Int" gtry $ runStmt "print (Y 3)" RunToCompletion :: GhcMonad m => m (Either SomeException RunResult) runDecls "data X = Y Int deriving Show" let stmt = "let __expr = 'x'" Just (ids, hval, fixenv) <- withSession $ \hsc_env -> liftIO $ hscStmt hsc_env stmt vals <- liftIO (unsafeCoerce hval :: IO [Char]) liftIO $ print vals -- thish prints "x", as expected runStmt "print (Y 8)" RunToCompletion }}} I have not tested with GHC API other than 7.6.3, and could not find a bug that was similar to this. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8628> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #8497: clang/wrapper cannot build GHC head with integer-gmp on Mavericks
by GHC 14 Jan '14

14 Jan '14

#8497: clang/wrapper cannot build GHC head with integer-gmp on Mavericks ----------------------------------+---------------------------------------- Reporter: kazu-yamamoto | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: clang | Operating System: MacOS X Architecture: | Type of failure: Building GHC failed Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | ----------------------------------+---------------------------------------- I'm using GHC 7.6.3 with clang/wrapper (setting is modified). This GHC cannot build GHC head with integer-gmp: {{{ checking for assembler byte directive... .byte checking how to define a 32-bit word... /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/nm: can't open file: conftest.o (No such file or directory) /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/nm: can't open file: conftest.o (No such file or directory) /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/nm: can't open file: conftest.o (No such file or directory) configure: error: cannot determine how to define a 32-bit word make[1]: *** [libraries/integer-gmp/gmp/gmp.h] Error 1 make: *** [all] Error 2 }}} With integer-simple, build is OK. For more information, please see http://d.hatena.ne.jp/kazu- yamamoto/20131028/1382921924 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8497> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #8616: "Internal error" with ScopedTypeVariables and kind variables
by GHC 13 Jan '14

13 Jan '14

#8616: "Internal error" with ScopedTypeVariables and kind variables ------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | 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: | ------------------------------------+------------------------------------- When I try to compile the following nonsense with HEAD {{{ {-# LANGUAGE PolyKinds, RankNTypes, ScopedTypeVariables #-} import Data.Proxy import GHC.Exts withSomeSing :: forall (kproxy :: k). Proxy kproxy withSomeSing = undefined :: (Any :: k) }}} I get this {{{ GHC internal error: ‛k’ is not in scope during type checking, but it passed the renamer tcl_env of environment: [(a4XG, Type variable ‛kproxy’ = kproxy), (r4MW, Identifier[withSomeSing::forall (k :: BOX) (kproxy :: k). Proxy k kproxy, <NotTopLevel>])] In the kind ‛k’ In an expression type signature: (Any :: k) In the expression: undefined :: (Any :: k) }}} The code is very bogus, but so is GHC's response. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8616> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #8590: Reduce code size of CAFs
by GHC 12 Jan '14

12 Jan '14

#8590: Reduce code size of CAFs ------------------------------------+------------------------------------- Reporter: parcs | Owner: parcs Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (NCG) | 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: | ------------------------------------+------------------------------------- The size of each CAF could be reduced by moving the code that allocates the blackhole indirection closure out from the CAF's closure body and into `newCAF`. This saves around 50 bytes of object code per CAF. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8590> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

[GHC] #8599: Deriving in associated data families
by GHC 10 Jan '14

10 Jan '14

#8599: Deriving in associated data families ------------------------------------+------------------------------------- Reporter: mojojojo | 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: | ------------------------------------+------------------------------------- This code {{{ class Class a where data DF a data family DF' a instance (Eq (DF' a)) => Class a where newtype DF a = DF (DF' a) deriving (Eq) }}} fails with {{{ No instance for (Eq (DF' a)) arising from the 'deriving' clause of a data type declaration Possible fix: add an instance declaration for (Eq (DF' a)) or use a standalone 'deriving instance' declaration, so you can specify the instance context yourself When deriving the instance for (Eq (DF a)) }}} The following way it compiles fine, however {{{ class Class a where data DF a data family DF' a instance Class a where newtype DF a = DF (DF' a) deriving instance (Eq (DF' a)) => Eq (DF a) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8599> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #8630: Kind inference fails to account for associated types
by GHC 10 Jan '14

10 Jan '14

#8630: Kind inference fails to account for associated types -------------------------------------------+------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type checker) | Version: 7.7 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: -------------------------------------------+------------------------------- Consider this: {{{ {-# LANGUAGE PolyKinds, TypeFamilies, FlexibleInstances #-} class C a where type F a instance C a where type F a = a -> a }}} HEAD gives me {{{ Expected a type, but ‛a’ has kind ‛k’ In the type ‛a -> a’ In the type instance declaration for ‛F’ In the instance declaration for ‛C a’ }}} The problem is that the use of `(->)` in the RHS of the definition for the `F a` instance constrains `a` to be of kind `*`, but GHC does not propagate this information back to the instance head. This decision is in conflict with the behavior for ''class'' declarations (as opposed to ''instance'' declarations), where a type variable's use in the definition informs its kind in the head. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8630> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #8622: Importing modules in .ghci file doesn't not work
by GHC 10 Jan '14

10 Jan '14

#8622: Importing modules in .ghci file doesn't not work ----------------------------------+--------------------------------- Reporter: m4dc4p | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Keywords: | Operating System: MacOS X Architecture: x86_64 (amd64) | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+--------------------------------- When attempting to import a module in the .ghci file, GHCi does not seem to use the search path. Define a module names "Macros.hs": {{{ module Macros where hello :: String -> IO String hello msg = return ("putStrLn " ++ show msg) }}} Now, in the same directory, create a .ghci file: {{{ import Macros :def hello hello }}} Run GHCi from that same directory, and you get an error: {{{ $ ghci GHCi, version 7.6.3: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. <no location info>: Could not find module `Macros' It is not a module in the current program, or in any known package. <interactive>:1:25: Not in scope: `hello' }}} It seems that GHCi should be able to find "Macros.hs", compile it, and all me to use it in defining macros. Adding the current directory (relative or absolute) to the search path (using -i) doesn't help. Why do I want to do this? I want to define GHCi macros in a separate module (that is not related to my program) and import them, rather than defining them directly in the .ghci file. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8622> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #8644: 'Untouchable' error with constraint variable in rank-2 type
by GHC 10 Jan '14

10 Jan '14

#8644: 'Untouchable' error with constraint variable in rank-2 type -------------------------------------+------------------------------------- Reporter: sbarclay | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.7 checker) | Operating System: Unknown/Multiple Keywords: | Type of failure: GHC rejects Architecture: Unknown/Multiple | valid program Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- The following program compiles fine with GHC 7.6.3: {{{#!haskell {-# LANGUAGE ConstraintKinds, RankNTypes, GADTs #-} data Dict c where Dict :: c => Dict c foo :: Dict c -> (c => r) -> r foo Dict x = x bar :: Dict () bar = Dict main :: IO () main = print $ foo bar "Hello" }}} However, it produces the following error with HEAD: {{{ ConstraintIssue.hs:12:8: No instance for (Show s0) arising from a use of ‛print’ The type variable ‛s0’ is ambiguous Note: there are several potential instances: instance Show Double -- Defined in ‛GHC.Float’ instance Show Float -- Defined in ‛GHC.Float’ instance (Integral a, Show a) => Show (GHC.Real.Ratio a) -- Defined in ‛GHC.Real’ ...plus 24 others In the expression: print In the expression: print $ foo bar "Hello" In an equation for ‛main’: main = print $ foo bar "Hello" ConstraintIssue.hs:12:24: Couldn't match expected type ‛s0’ with actual type ‛[Char]’ ‛s0’ is untouchable inside the constraints (()) bound by a type expected by the context: (()) => s0 at ConstraintIssue.hs:12:16-30 In the second argument of ‛foo’, namely ‛"Hello"’ In the second argument of ‛($)’, namely ‛foo bar "Hello"’ In the expression: print $ foo bar "Hello" }}} If the type signature of 'main' is removed, the code compiles OK. If the empty constraint () is replaced with an equality constraint such as Int ~ Int, then the above error occurs with both 7.6.3 and HEAD, which I guess is intended behaviour. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8644> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #8601: runghc from standard input and --ghc-args
by GHC 07 Jan '14

07 Jan '14

#8601: runghc from standard input and --ghc-args ------------------------------------+------------------------------------- Reporter: wuzzeb | 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: | ------------------------------------+------------------------------------- I am trying to use runghc with a cabal sandbox, and it works when the haskell code is in a file like follows: {{{ runghc -- -package-db --ghc-arg=.cabal-sandbox/i386-linux- ghc-7.6.3-packages.conf.d somefile.hs }}} But if I try and load the script from standard input (actually I am trying to run a GHC script from a bash script using "runghc << EOF" but it is easier to see if you just run from the console) {{{ runghc -- -package-db --ghc-arg=.cabal-sandbox/i386-linux- ghc-7.6.3-packages.conf.d < somefile.hs }}} you get an error {{{ .cabal-sandbox/i386-linux-ghc-7.6.3-packages.conf.d/:1:57: Not in scope: `main' Perhaps you meant `min' (imported from Prelude) }}} Looking at the utils/runghc/runghc.hs source file, what happens is inside the doIt function. The first thing the doIt function does is call getGhcArgs which strips the --ghc-args. Then it checks the args and sees there is no file, so falls into the case where it reads standard input, creates a temp file, and then recalls doIt. Here is the problem, because the "--ghc-arg" string has already been stripped so the second call to doIt is where the error occurs. With that, I can actually get it to work with the following :) {{{ runghc -- -package-db --ghc-arg=--ghc-arg=.cabal-sandbox/i386-linux- ghc-7.6.3-packages.conf.d < somefile.hs }}} By passing --ghc-arg= twice, it is stripped once the first time doIt is called and once the second time and GHC gets the correct args :) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8601> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4