February 2013 - ghc-tickets

[GHC] #7643: Kind application error
by GHC 13 Apr '13

13 Apr '13

#7643: Kind application error -----------------------------+---------------------------------------------- Reporter: gmainland | Owner: Type: bug | Status: new Priority: normal | Component: Compiler (Type checker) Version: 7.6.1 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- Compiling the attached program with -dcore-lint fails. This failure is a reduced version of code taken from the primitive package, version 0.5.0.1. To see the failure: {{{ ghc -dcore-lint --make Main.hs }}} The failure does not occur with GHC 7.4. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7643> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #7637: split-objs not supported for ARM
by GHC 13 Apr '13

13 Apr '13

#7637: split-objs not supported for ARM -----------------------------------------+---------------------------------- Reporter: singpolyma | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler Version: 7.7 | Keywords: Os: Unknown/Multiple | Architecture: arm Failure: Compile-time performance bug | Blockedby: Blocking: | Related: -----------------------------------------+---------------------------------- As reported in http://www.haskell.org/pipermail/ghc- devs/2013-January/000198.html -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7637> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #7635: SafeHaskell implying other options
by GHC 13 Apr '13

13 Apr '13

#7635: SafeHaskell implying other options ----------------------------------------+----------------------------------- Reporter: shachaf | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler Version: 7.6.1 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: GHC accepts invalid program | Blockedby: Blocking: | Related: ----------------------------------------+----------------------------------- There have been several type checker bugs -- including #7453 and #7354 -- that have led to type-checker unsafeCoerce/panic/etc., which is a problem under SafeHaskell. In many cases the issue is caught by `-dcore-lint`. I'm not sure how much overhead core-linting has, but it seems like it could be a good idea to turn it on by default at least when SafeHaskell is on. Right now it's listed as a "compiler debugging option", but it seems that common wisdom is that you should use it if you care about security. Should you also use `stg-lint`/`cmm-lint`? Any other options? This should be clearly documented. Relatedly: Earlier today someone was running a Haskell-evaluating IRC bot. It was running with SafeHaskell, but also happened to have GeneralizedNewtypeDeriving turned on, which made it possible to derive `unsafeCoerce`. Should more care be taken that unsafe options are never turned on at the same time as SafeHaskell? (Continued from #7354.) -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7635> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #7634: MD5 collision could lead to SafeHaskell violation
by GHC 13 Apr '13

13 Apr '13

#7634: MD5 collision could lead to SafeHaskell violation -----------------------------+---------------------------------------------- Reporter: shachaf | Owner: Type: bug | Status: new Priority: normal | Component: libraries/base Version: 7.6.1 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Other | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- The current scheme for computing `TypeRep` fingerprints is: `md5sum (encodeUTF32BE (unwords [moduleName, packageName, typeName]))`. `SafeHaskell` doesn't allow custom-written `Typeable` instances, but this is more or less the code that `deriving Typeable` generates. MD5 is broken and not collision-resistant. If someone can make an MD5 collision, they could use it to derive `unsafeCoerce` and execute arbitrary code. The constraints (UTF-32, names being alphanumeric, etc.) make it pretty tricky to find a valid collision by the standard methods, but I don't know enough about this to say how feasible it is. It seems to me that, especially with `new-typeable`, it might not be necessary to use hashing at all, if GHC can figure out fingerprints statically. Or maybe separate compilation requirements make that unworkable (in which case maybe using a hash of the package/module name along with a separate per-module counter, or something along those lines, might be better, since people are less likely to control those? I'm not sure). Maybe the solution is just switching to another hash function, or something else. At any rate, the issue should be considered -- using MD5 isn't a good idea in cases where collisions could have security implications. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7634> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #7654: Cannot specify argv[0] with createProcess
by GHC 13 Apr '13

13 Apr '13

#7654: Cannot specify argv[0] with createProcess -----------------------------+---------------------------------------------- Reporter: MtnViewMark | Owner: Type: feature request | Status: new Priority: normal | Component: libraries/process Version: 7.6.2 | Keywords: process Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- There are conditions where it is important to specify the value of argv[0] as distinct from the FilePath of the file to execute. When createProcess is called with CmdSpec (inside the CreateProcess argument) of RawCommand, the code in System.Process.Internals.runGenProcess_ builds the argv list by concatenating the FilePath of the command to run on to the supplied args, then passing that array to the c code runInteractiveProcess. runInteractiveProcess in turn uses argv[0] as the initial argument to either execvp() or execvpe(). Thus, argv[0], and the command to execute must be the same. The fix is simple, but long.... runInteractiveProcess should take an adiditional parameter that is the command to exec, distinct from the args array (which continues to hold the now distinct argv[0]). runGenProcess_ should keep cmd and args distinct, and build cstrs from args, not cmd:args. commandToProcess needs to then take on the work of prepending the cmd to the args array, in the case of RawCommand or ShellCommand. NOW, we can introduce a new constructore RawCommandWithArg0 FilePath String [String] where argv[0] is specified, and commandToProcess for that can easily build the args from that parameter. I should probably prepare a patch for this.... But I wanted to get the ticket in as the issue was fresh in my mind. This is a feature request, but realize that without a change, an important part of POSIX support is missing. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7654> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #7625: Semicolon is not handled between imports at the ghci command prompt
by GHC 13 Apr '13

13 Apr '13

#7625: Semicolon is not handled between imports at the ghci command prompt -----------------------------+---------------------------------------------- Reporter: JohnWiegley | Owner: Type: bug | Status: new Priority: normal | Component: GHCi Version: 7.4.2 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Other | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- You cannot use "import Data.List ; import Control.Monad" at the ghci command prompt. It gives: <no location info>: parse error in import declaration -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7625> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #7624: Handling ImplicitParams in Instance Declaration
by GHC 13 Apr '13

13 Apr '13

#7624: Handling ImplicitParams in Instance Declaration ------------------------------+--------------------------------------------- Reporter: philipjf | Owner: Type: bug | Status: new Priority: normal | Component: Documentation Version: 7.6.1 | Keywords: ImplicitParams Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Documentation bug | Blockedby: Blocking: | Related: ------------------------------+--------------------------------------------- The GHC documentation states that ImplicitParam's may not be used in class or instance declaration constraints. see for example http://www.haskell.org/ghc/docs/7.6.1/html/users_guide/other-type- extensions.html In practice though, at least on the Mac, all recent version of GHC have permitted such instances. At the very least the documentation should make clear that the compiler might permit such instances, but they have undefined behaviour. Ideally, these would simply be permitted. [http://joyoftypes.blogspot.com/2013/01/using-compiler-bugs-for-fun-and- profit.html Why I think the (undocumented) current behavior is correct] -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7624> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #7623: GHC Arm support
by GHC 13 Apr '13

13 Apr '13

#7623: GHC Arm support -------------------------------+-------------------------------------------- Reporter: dterei | Owner: Type: task | Status: new Priority: normal | Component: Compiler Version: 7.7 | Keywords: Os: Unknown/Multiple | Architecture: arm Failure: Compile-time crash | Blockedby: Blocking: | Related: -------------------------------+-------------------------------------------- Top level to track some important fixes for proper ARM support of GHC. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7623> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #7619: Make worker-wrapper unbox data families
by GHC 13 Apr '13

13 Apr '13

#7619: Make worker-wrapper unbox data families -----------------------------+---------------------------------------------- Reporter: akio | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler Version: 7.7 | Keywords: type family Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- I noticed that the worker-wrapper optimization doesn't unbox arguments whose type is a data family instance. For example in this module: {{{ {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE BangPatterns #-} module Foo where data family Foo a data instance Foo Int = FooInt Int Int foo :: Foo Int -> Int foo (FooInt a b) = loop a b where loop 0 y = length $ replicate y b loop x !y = loop (mod y x) x foo1 :: (Int, Int) -> Int foo1 (a, b) = loop a b where loop 0 y = length $ replicate y b loop x !y = loop (mod y x) x }}} foo and foo1 both get worker-wrapper applied, with worker functions of the following types: {{{ $wfoo :: Foo Int -> Int# $wfoo1 :: Int# -> Int# -> Int# }}} It would be nice if $wfoo could get the same type as $wfoo1. This issue happened in real life with unboxed vectors from the vector package, resulting in a lot of boxing with unboxed vector constructors immediately followed by unboxing. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7619> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #7618: Multiline prompt ignores custom prompt
by GHC 13 Apr '13

13 Apr '13

#7618: Multiline prompt ignores custom prompt -------------------+-------------------------------------------------------- Reporter: dunric | Owner: Type: bug | Status: new Priority: normal | Component: GHCi Version: 7.6.1 | Keywords: Os: Linux | Architecture: x86_64 (amd64) Failure: Other | Blockedby: Blocking: | Related: #5209 -------------------+-------------------------------------------------------- 1. start a ghci session Prelude> 2. set some custom prompt Prelude> :set prompt "GHCi> " GHCi> 3. start a multiline command GHCi> :{ Prelude| Expected "GHCi| " as the custom prompt in multiline command. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7618> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2