- ghc-tickets - Haskell.org

[GHC] #9563: Support for deriving Generic1 for data families
by GHC 07 Apr '16

07 Apr '16

#9563: Support for deriving Generic1 for data families -------------------------------------+------------------------------------- Reporter: mnislaih | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: GHC Difficulty: Unknown | rejects valid program Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- The following code: {{{#!hs import GHC.Generics data family F typ :: * -> * data A data instance F A a = AData a deriving Generic1 }}} produces an error when run with ghc 7.8.2 or 7.8.3: {{{ Couldn't match type ‘Rep1 (F A)’ with ‘M1 t0 t1 (M1 t2 t3 (M1 t4 t5 Par1))’ The type variables ‘t0’, ‘t1’, ‘t2’, ‘t3’, ‘t4’, ‘t5’ are ambiguous Expected type: Rep1 (F A) a Actual type: M1 t0 t1 (M1 t2 t3 (M1 t4 t5 Par1)) a In the pattern: M1 (M1 (M1 g1)) In an equation for ‘to1’: to1 (M1 (M1 (M1 g1))) = AData (unPar1 g1) In the instance declaration for ‘Generic1 (F A)’ }}} whereas ghc 7.6.3 simply refuses to go ahead with the message: {{{ generic1.hs:14:40: Derived instance `Generic1 (F A)' requires illegal partial application of data type family F In the data instance declaration for `F' }}} Either a check has gone missing in 7.8.x, or a bug has crept up in the Generic1 support. I have gone through past tickets and https://ghc.haskell.org/trac/ghc/ticket/5936 suggests that it is the latter. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9563> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #10513: ghc 7.6.3 Compiler panic with Generics
by GHC 07 Apr '16

07 Apr '16

#10513: ghc 7.6.3 Compiler panic with Generics -------------------------------------+------------------------------------- Reporter: | Owner: andreas.abel | Status: new Type: bug | Milestone: Priority: normal | Version: 7.6.3 Component: Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Currently, Agda only compiles with ghc 7.4, 7.8, and 7.10, see https://code.google.com/p/agda/issues/detail?id=1558 Here is a the relevant commit: https://github.com/agda/agda/commit/f7b47de0cb167514f6db859b204abd638887b76f Generics do not seem to work properly in ghc 7.6 {{{ [ 92 of 312] Compiling Agda.Syntax.Abstract.Name ( src/full/Agda/Syntax/Abstract/Name.hs, dist/build/Agda/Syntax/Abstract/Name.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.6.3 for x86_64-unknown-linux): tcIfaceGlobal (local): not found: Agda-2.4.3:Agda.Syntax.Fixity.D1PrecedenceLevel{tc a4mIV} [(rc0D, Type constructor `Agda-2.4.3:Agda.Syntax.Fixity.Fixity'{tc rc0D}'), (r4mFT, Type constructor `Agda-2.4.3:Agda.Syntax.Fixity.Precedence{tc r4mFT}'), […] (r4mKa, Identifier `Agda-2.4.3:Agda.Syntax.Fixity.$fTypeable1ThingWithFixity{v r4mKa}'), (r4mKb, Identifier `Agda-2.4.3:Agda.Syntax.Fixity.$fGenericThingWithFixity{v r4mKb}'), (r4mKc,ghc: panic! (the 'impossible' happened) (GHC version 7.6.3 for x86_64-unknown-linux): ghc: panic! (the 'impossible' happened) (GHC version 7.6.3 for x86_64-unknown-linux): tcIfaceGlobal (local): not found: <<details unavailable>> Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} I don't know whether you are maintaining old ghcs, but it seems we have to drop Generics until we drop support for ghc 7.6 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10513> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #10669: Missing Generic instances for base types.
by GHC 07 Apr '16

07 Apr '16

#10669: Missing Generic instances for base types. -------------------------------------+------------------------------------- Reporter: vagarenko | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.10.1 libraries/base | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- There is instance Generic Int in GHC.Generics, but no Generic Word. Also there is no Generic instances for Int8, Int16, Int32, Int64, Word8, Word16, Word32, Word64. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10669> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #10868: Make GHC generics capable of handling unboxed types
by GHC 07 Apr '16

07 Apr '16

#10868: Make GHC generics capable of handling unboxed types -------------------------------------+------------------------------------- Reporter: | Owner: RyanGlScott RyanGlScott | Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #8468 Differential Revisions: | -------------------------------------+------------------------------------- Currently, GHC generics will not accept any unboxed constructor arguments: {{{ $ ghci GHCi, version 7.10.2: http://www.haskell.org/ghc/ :? for help λ> :set -XMagicHash -XDeriveGeneric λ> :m + GHC.Generics GHC.Exts λ> data IntHash = IntHash Int# deriving Generic <interactive>:4:38: Can't make a derived instance of ‘Generic IntHash’: IntHash must not have unlifted or polymorphic arguments In the data declaration for ‘IntHash’ }}} This makes GHC generics strictly less powerful than `deriving` clauses in some scenarios, as typeclasses like `Eq`, `Ord`, and `Show` are capable of special-casing certain unboxed types: {{{ λ> :set -ddump-deriv λ> data IntHash = IntHash Int# deriving Show ==================== Derived instances ==================== Derived instances: instance GHC.Show.Show Ghci1.IntHash where GHC.Show.showsPrec a_a1OJ (Ghci1.IntHash b1_a1OK) = GHC.Show.showParen ((a_a1OJ GHC.Classes.>= 11)) ((GHC.Base..) (GHC.Show.showString "IntHash ") (GHC.Show.showsPrec 11 (GHC.Types.I# b1_a1OK))) GHC.Show.showList = GHC.Show.showList__ (GHC.Show.showsPrec 0) }}} As discussed on the GHC devs mailing list [https://mail.haskell.org/pipermail/ghc-devs/2015-September/009895.html previously], Andres suggested adding new generic representation types to mark where `Int#`, `Char#`, etc. are used (suggesting the name `UInt` to represent `Int#`). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10868> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #11292: Generics unboxed types: TEST=GEq1 WAY=optasm is failing
by GHC 07 Apr '16

07 Apr '16

#11292: Generics unboxed types: TEST=GEq1 WAY=optasm is failing -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{ $ make TEST=GEq1 WAY=optasm TEST_HC=ghc-7.11.20151225 ... cd ./generics/GEq && ./GEq1 </dev/null > GEq1.run.stdout 2> GEq1.run.stderr Actual stdout output differs from expected: --- ./generics/GEq/GEq1.stdout.normalised 2015-12-26 15:32:22.984189653 +0100 +++ ./generics/GEq/GEq1.run.stdout.normalised 2015-12-26 15:32:22.984189653 +0100 @@ -3,5 +3,5 @@ True True False -True -True \ No newline at end of file +False +False \ No newline at end of file *** unexpected failure for GEq1(optasm) }}} The test was last touched by Ryan in 6cde981a8788b225819be28659caddc35b77972d (#10868) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11292> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 16

[GHC] #11775: singleton classes in ghc.generics are defined but not exported
by GHC 07 Apr '16

07 Apr '16

#11775: singleton classes in ghc.generics are defined but not exported -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I noticed in the bottom of the GHC.Generics module in the RC candidate that theres some type classea and instnaces involving singletons included and notated as copied from the singletons package but not exported {{{ -------------------------------------------------------------------------------- -- Copied from the singletons package -------------------------------------------------------------------------------- -- | The singleton kind-indexed data family. data family Sing (a :: k) -- | A 'SingI' constraint is essentially an implicitly-passed singleton. -- If you need to satisfy this constraint with an explicit singleton, please -- see 'withSingI'. class SingI (a :: k) where -- | Produce the singleton explicitly. You will likely need the @ScopedTypeVariables@ -- extension to use this method the way you want. sing :: Sing a -- | The 'SingKind' class is essentially a /kind/ class. It classifies all kinds -- for which singletons are defined. The class supports converting between a singleton -- type and the base (unrefined) type which it is built from. class (kparam ~ 'KProxy) => SingKind (kparam :: KProxy k) where -- | Get a base type from a proxy for the promoted kind. For example, -- @DemoteRep ('KProxy :: KProxy Bool)@ will be the type @Bool@. type DemoteRep kparam :: * -- | Convert a singleton to its unrefined version. fromSing :: Sing (a :: k) -> DemoteRep kparam }}} etc, is this deliberate? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11775> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #10030: packageName for GHC.Generics.Datatype
by GHC 07 Apr '16

07 Apr '16

#10030: packageName for GHC.Generics.Datatype -------------------------------------+------------------------------------- Reporter: phadej | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.4 Component: | Operating System: Unknown/Multiple libraries/base | Type of failure: None/Unknown Keywords: | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Seems it's perfectly ok to have the data type of the same name in the same module, but different packages. Yet used in the same module: {{{ {-# LANGUAGE PackageImports #-} {-# LANGUAGE RankNTypes #-} module Data.Foo where import "void" Data.Void as A import Data.Void as B foo :: A.Void -> a foo = absurd bar :: B.Void -> a bar x = x () }}} {{{ {-# LANGUAGE RankNTypes #-} module Data.Void where type Void = forall a b. a -> b }}} https://gist.github.com/phadej/8b628d579ddf6958d937 motivated by: http://stackoverflow.com/questions/28159068/packagename- with-ghc-generics I'd propose to change `Datatype` class to be: {{{ class Datatype d where -- | The name of the datatype (unqualified) datatypeName :: t d (f :: * -> *) a -> [Char] -- | The fully-qualified name of the module where the type is declared moduleName :: t d (f :: * -> *) a -> [Char] -- | The package name of the module where the type is declared packageName :: t d (f :: * -> *) a -> [Char] -- | Marks if the datatype is actually a newtype isNewtype :: t d (f :: * -> *) a -> Bool isNewtype _ = False }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10030> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #11807: -fforce-relink / -fforce-link option
by GHC 07 Apr '16

07 Apr '16

#11807: -fforce-relink / -fforce-link option -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I would quite like it if there was an option for GHC to force relinking, in case GHC mistakenly does not think relinking is necessary. For example, if I am doing development on a statically linked RTS I may want to force relinking on executables to get the new RTS. `-fforce-recomp` works OK for small cases, but it forces recompilation of the modules too which is unnecessary. I could have sworn there was already a ticket for this but I could not find it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11807> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8594: sysctl name "hw.ncpu" (HW_NCPU) is deprecated in Mac OS X
by GHC 07 Apr '16

07 Apr '16

#8594: sysctl name "hw.ncpu" (HW_NCPU) is deprecated in Mac OS X ------------------------------------+--------------------------------- Reporter: kseo | Owner: simonmar Type: task | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.6.3 Keywords: | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+--------------------------------- According to the OS X man page for sysctl(https://developer.apple.com/library/mac/documentation/Darwin/Referen…, HW_NCPU used by the current implementation of getNumberOfProcessors() is deprecated. Instead, Mac OS X provides the following 4 options: * hw.physicalcpu: The number of physical processors available in the current power management mode. * hw.physicalcpu_max: The maximum number of physical processors that could be available this boot. * hw.logicalcpu: The number of logical processors available in the current power management mode. * hw.logicalcpu_max: The maximum number of logical processors that could be available this boot. I am not sure which one fits best to GHC runtime. Any idea? sysconf implementation of getNumberOfProcessors() seems to prefer _SC_NPROCESSORS_ONLN to _SC_NPROCESSORS_CONF when both are defined. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8594> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #11698: GHC's tct_closed flag is not being set correctly
by GHC 07 Apr '16

07 Apr '16

#11698: GHC's tct_closed flag is not being set correctly -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The `Note [Bindings with closed types]` in `TcEnv` describes when a binding is "closed", which in turn affects generalisation. (See the Note for details.) But the implementation doesn't follow the Note. Instead it uses this function in `TcEnv`: {{{ isClosedLetBndr :: Id -> TopLevelFlag -- See Note [Bindings with closed types] in TcRnTypes -- Note that we decided if a let-bound variable is closed by -- looking at its type, which is slightly more liberal, and a whole -- lot easier to implement, than looking at its free variables isClosedLetBndr id | isEmptyVarSet (tyCoVarsOfType (idType id)) = TopLevel | otherwise = NotTopLevel }}} It may be easier but it's also wrong. Consider {{{ f x = ( let g y = x+y in ... , x::Int) }}} Is `g` closed (which affects how definitions in `...` are generalised)? Well if we typecheck the second element of the tuple first, we may "know" that `x::Int` by the time we are inferring a type for `g`, conclude that `g` has no free type variables, and say that it is closed. But if we do the `x::Int` part second, so while type checking the `let` we think that `x::alpha`, then we'll say that `g` is open. This looks nasty. I think we should do it the way the `Note` says. Thanks to Facundo for pointing this out. Not urgent, but plainly wrong. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11698> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8