January 2013 - ghc-tickets

[GHC] #7644: Hackage docs for base library contain broken links
by GHC 12 Apr '13

12 Apr '13

#7644: Hackage docs for base library contain broken links -----------------------------+---------------------------------------------- Reporter: JulesBean | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.6.1 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- http://hackage.haskell.org/packages/archive/base/4.6.0.0/doc/html/GHC- IOArray.html Is a 404, presumably because it's {{{ {-# HADDOCK_OPTIONS hide #-} }}} so the haddocks don't get documented? However it is linked to from the master index http://hackage.haskell.org/package/base-4.6.0.0 ...which as far as I can see has links to all modules irrespective of whether they are hidden or not. A different example relates to source links: If you look at the Prelude docs here: http://hackage.haskell.org/packages/archive/base/4.6.0.0/doc/html/Prelude.h… Then some of the source links point to URLs like http://hackage.haskell.org/packages/archive/%01/%02/doc/html/src/GHC- Classes.html#Ord ...which looks like some substitution operation has failed (%01 -> package name, %02 -> version, I presume). An attempt to manually fix the package name and version still leads to a 404. Some other source links from the Prelude are fine, though, for example: http://hackage.haskell.org/packages/archive/base/4.6.0.0/doc/html/src/GHC- Enum.html#Enum This is a regression but I don't know how recently; I certainly used to be able to follow links like that back in the 7.0 era, but I don't when it started failing. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7644> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

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

12 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 12 Apr '13

12 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 12 Apr '13

12 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 12 Apr '13

12 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] #7625: Semicolon is not handled between imports at the ghci command prompt
by GHC 12 Apr '13

12 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 12 Apr '13

12 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 12 Apr '13

12 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 12 Apr '13

12 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 12 Apr '13

12 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