June 2013 - ghc-tickets

Re: [GHC] #4417: Quasiquoting without bloating
by GHC 25 Jun '13

25 Jun '13

#4417: Quasiquoting without bloating -------------------------------+-------------------------------------------- Reporter: rrnewton | Owner: simonmar Type: feature request | Status: closed Priority: high | Milestone: 7.4.1 Component: Compiler | Version: 6.13 Resolution: fixed | Keywords: executable size Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Testcase: | Blockedby: Blocking: | Related: -------------------------------+-------------------------------------------- Changes (by gidyn): * cc: gideon@… (removed) -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4417#comment:15> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8012: Warn when using Enum instance for Float or Double
by GHC 25 Jun '13

25 Jun '13

#8012: Warn when using Enum instance for Float or Double -----------------------------+---------------------------------------------- Reporter: gidyn | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler Version: 7.6.3 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- The Enum instances for Float and Double have dubious semantics which cause endless confusion, e.g. [http://stackoverflow.com/questions/13203471/the-math- behind-1-0999999999999999-in-haskell], [http://stackoverflow.com/questions/9810002/floating-point-list- generator], [http://stackoverflow.com/questions/7290438/haskell-ranges-and-floats] [http://stackoverflow.com/questions/10328435/how-to-solve-floating-point- number-getting-wrong-in-list-haskell], and many more. It is therefore proposed that the usage of an Enum instance for Float or Double generate a compiler warning, such as "The Enum instance for Float is subject to rounding errors". A discussion of this on [http://haskell.1045720.n5.nabble.com/Proposal- Warn-when-using-Enum-instance-of-Float-or-Double-td5731620.html the libraries list] suggested that such a warning would be desired, although the discussion mostly focused on whether the libraries list is an appropriate place for this discussion. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/8012> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #8010: Add forkOSUnmasked (patch)
by GHC 25 Jun '13

25 Jun '13

#8010: Add forkOSUnmasked (patch) -----------------------------+---------------------------------------------- Reporter: joeyadams | Owner: Type: feature request | Status: new Priority: normal | Component: libraries/base Version: 7.7 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- This patch simply adds `forkOSUnmasked` to Control.Concurrent: {{{ -- | Like 'forkIOWithUnmask', but the child thread is a bound thread, -- as with 'forkOS'. forkOSWithUnmask :: ((forall a . IO a -> IO a) -> IO ()) -> IO ThreadId forkOSWithUnmask io = forkOS (io unsafeUnmask) }}} I ran `sh validate`, and no new failures were introduced. I'll push it to master in a few days, unless someone objects. For GHC < 7.8, `forkOSWithUnmask` can be achieved using `forkOS` and [http://hackage.haskell.org/packages/archive/base/4.6.0.1/doc/html /Control-Exception.html#v:block block], but `block` is removed in GHC 7.8. `unsafeUnmask` can still be imported from `GHC.IO`, however. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/8010> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #7961: Remove restrictions on promoting GADT's
by GHC 24 Jun '13

24 Jun '13

#7961: Remove restrictions on promoting GADT's -----------------------------+---------------------------------------------- Reporter: danharaj | Owner: Type: feature request | Status: new Priority: normal | Component: Compiler Version: 7.6.3 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: #6204 -----------------------------+---------------------------------------------- (Also allow the promotion of data types whose kind is not (* -> ... -> *)) I have been using -XDataKinds lately to explore the sorts of dependently typed programming that are currently possible in GHC. I am particularly interested in DSL's and embedding other languages' type systems into Haskell so that GHC can help verify the correctness of the program fragments I construct for those languages. From my point of view as an end-user, the restrictions on what data get promoted is inconsistent and oftentimes annoying to deal with. There are two related issues on my end: 1. The restriction that a data type cannot have a kind mentioning a promoted kind means that the way I stratify my type machinery impacts whether or not GHC will promote everything as I would like. 2. The inability to use promoted GADT's forces me to encode relationships between my type building blocks in trickier ways, and sometimes I am simply unable to come up with an alternative. I have found that these issues get in my way as a programmer of modest skill. Oftentimes I will explore a particular design but be forced to abandon it because my "natural" line of reasoning runs into GHC's restrictions. With sufficient cleverness you can do quite a lot of impressive stuff with the current system, but I am often not sufficiently clever nor am I equipped to determine when something is outright ''impossible''. Lifting these restriction, from ''my'' point of view, would simplify the machinery a great deal and allow me to do type-level programming that is currently out of my reach. It would make the kind extensions more uniform and more complete to us end-users. #6204 would complete them in another way. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7961> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #7995: module Pretty's "text/str" rule doesn't fire
by GHC 24 Jun '13

24 Jun '13

#7995: module Pretty's "text/str" rule doesn't fire -----------------------------+---------------------------------------------- Reporter: parcs | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.7 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- In this trivial but characteristic example {{{ import Pretty import Data.IORef main :: IO () main = do _ <- newIORef (text "test") return () }}} the "text/str" rule, which optimizes calls to `Pretty.text` applied to a string literal argument, doesn't fire. Likewise, such calls to `Outputable.text` don't get rewritten either. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7995> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #8002: Type family causing GHC to hang on recompilation
by GHC 24 Jun '13

24 Jun '13

#8002: Type family causing GHC to hang on recompilation -----------------------------+---------------------------------------------- Reporter: jweijers | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.6.3 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- I am having a problem with (re)compiling some code I have. I have two modules A and B. In A I have some classes and instances and B uses this. When I try to compile B (with cabal or ghc --make) the first time everything works. When I now modify B (add a space) B is recompiled but the compiler hangs and doesn't seems to be doing anything. I have tested the problem with GHC (x86_64) 7.6.2. 7.6.3 and HEAD (build on 20/06/2013). It seems to be very similar to a problem I had earlier: http://hackage.haskell.org/trac/ghc/ticket/7321 but this time there are no GADTs involved. The code of module A (clutter that doesn't contribute to the problem has been removed): {{{ > {-# LANGUAGE FlexibleInstances, UndecidableInstances #-} > {-# LANGUAGE GADTs #-} > {-# LANGUAGE MultiParamTypeClasses #-} > {-# LANGUAGE TypeFamilies, TypeOperators, ScopedTypeVariables #-} > {-# LANGUAGE FlexibleContexts #-} > {-# LANGUAGE DataKinds, PolyKinds #-} > > module A where > > import GHC.Generics > > class QA a where > type QRep a > type QRep a = QRep (GRep (Rep a)) > > instance QA () where > type QRep () = () > > -- Kind-polymorphic proxies; > data Pr (a :: k) = Pr > > class (QA (GRep f)) => CaseOf (f :: * -> *) where > type Alg f r k :: * > type GRep f :: * > > -- Only used for the product structure > class QA (ProdRep f) => CaseOfProd (f :: * -> *) where > type ProdAlg f r :: * > type ProdRep f :: * }}} The code of module B: {{{ > module B where > import qualified A }}} Given that the code type checks (and if I do not recompile and make an executable directly it actually works) I think this is a bug that might be similar to the bug mentioned in ticket 7321. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/8002> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

Re: [GHC] #5972: option to suppress (Monomorphic) record selector functions
by GHC 24 Jun '13

24 Jun '13

#5972: option to suppress (Monomorphic) record selector functions ---------------------------------+------------------------------------------ Reporter: AntC | Owner: adamgundry Type: feature request | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: Keywords: records | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Changes (by adamgundry): * cc: adam.gundry@… (added) * owner: igloo => adamgundry Comment: I'm looking at this as part of my work on [wiki:Records/OverloadedRecordFields/Plan implementing overloaded record fields]. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5972#comment:5> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8000: -ddump-minimal-imports should preserve imports of symbols in the export list
by GHC 24 Jun '13

24 Jun '13

#8000: -ddump-minimal-imports should preserve imports of symbols in the export list -----------------------------+---------------------------------------------- Reporter: dsf | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.6.3 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- Here is one more dump-minimal imports bug - for this module: {{{ module Foo (dropWhile) where import Data.List (dropWhile) }}} ghc -ddump-minimal-imports outputs {{{ import Data.List () }}} but the original module needs the import of {{{dropWhile}}} to compile. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/8000> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #7833: installed GHC refers to libffi in the build directory
by GHC 24 Jun '13

24 Jun '13

#7833: installed GHC refers to libffi in the build directory ---------------------------------+------------------------------------------ Reporter: igloo | Owner: igloo Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Build System | Version: 7.6.2 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ In #7806, Kazu reported that on OS X: After "make install", the installed GHC refers to libffi in the build directory. {{{ % otool -L ghc | grep libffi /Users/kazu/work/ghc/libffi/build/inst/lib/libffi.6.dylib (compatibility version 7.0.0, current version 7.0.0) }}} So, after I did "make maintainer-clean", the installed GHC could not find a libffi. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7833> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

2 12

[GHC] #7978: Profiling broken
by GHC 24 Jun '13

24 Jun '13

#7978: Profiling broken ------------------------------------+--------------------------------------- Reporter: gmainland | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.7 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: GHC doesn't work at all | Blockedby: Blocking: | Related: ------------------------------------+--------------------------------------- The cardinality analysis patch broke profiling. This can be seen in the nightly builds, where the profasm and profthreaded ways show many, many failures. ghc:changeset:da4ff650 is good, and ghc:changeset:62653122 is bad; the intervening few changes are not buildable. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7978> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3