- ghc-tickets - Haskell.org

[GHC] #10935: More unused and non-deprecated warning flags
by GHC 21 Jan '16

21 Jan '16

#10935: More unused and non-deprecated warning flags -------------------------------------+------------------------------------- Reporter: osa1 | Owner: Type: task | Status: new Priority: lowest | 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: #10752 Differential Rev(s): | -------------------------------------+------------------------------------- For #10752 I was looking at some warning generation code, and I realized that these flags are not doing anything right now, but they're not deprecated: - -fwarn-tabs - -fwarn-monomorphism-restriction - -fwarn-unrecognised-pragmas This one is not even shown in user manual or man page: - Opt_WarnAlternativeLayoutRileTransitional We should probably deprecate and remove them. Another thing is that we should probably remove -fwarn-amp in HEAD. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10935> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #11464: Type casts cause confusing error
by GHC 21 Jan '16

21 Jan '16

#11464: Type casts cause confusing error -------------------------------------+------------------------------------- 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: -------------------------------------+------------------------------------- Try this {{{ instance Eq (Either a) }}} GHC HEAD gives {{{ Foo.hs:9:10: error: • Illegal instance declaration for ‘Eq (Either a)’ (All instance types must be of the form (T a1 ... an) where a1 ... an are *distinct type variables*, and each type variable appears at most once in the instance head. Use FlexibleInstances if you want to disable this.) • In the instance declaration for ‘Eq (Either a)’ Foo.hs:9:14: error: • Expecting one more argument to ‘Either a’ Expected a type, but ‘Either a’ has kind ‘* -> *’ • In the first argument of ‘Eq’, namely ‘Either a’ In the instance declaration for ‘Eq (Either a)’ }}} The second is right but the first is outright misleading. Reason: we elaborate to {{{ Eq (Either a |> g) }}} where `g` is a type-level kind cast; it's insoluble and gives rise to the second error. But the elaborated type confuses `checkValidInstHead`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11464> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #11065: Outdated documentation for foldl and friends
by GHC 21 Jan '16

21 Jan '16

#11065: Outdated documentation for foldl and friends -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Documentation | Version: 7.10.2 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: -------------------------------------+------------------------------------- Straight from `Data.Foldable`, here is the documentation for `foldl`: {{{ -- | Left-associative fold of a structure. -- -- @'foldl' f z = 'Prelude.foldl' f z . 'toList'@ }}} But, of course, `Prelude.foldl` is the same `foldl`! There are other functions with similar problems. When revising these, please put in (back?) examples of how these work, at least on lists. I've been doing functional programming for some time, and I still like to look at examples to make sure that I'm getting my `foldl` and `foldr` straight. Maybe it's because my brain is small, but we don't want to exclude people with small brains! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11065> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #10137: Rewrite switch code generation
by GHC 21 Jan '16

21 Jan '16

#10137: Rewrite switch code generation -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 (CodeGen) | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Inspired by #10124 I looked at the code generation for enumeration and integer types, and I think this can be improved in a few ways. My goals are: * Fancier code for integer types. Currently, the code for enumeration types will emit jump tables for dense choices; there is no reason to treat integer types differently. * The ability to behave differently if some of the cases are equal, and, as an extension of that, * The possibility to create branchless code if multiple checks would go to the same jump. The current scheme is roughly: * When we generate Cmm code for a STG case expression, we handle enumeration types and literals separately. * At this point, the decisions about what code to generate are made (jump tables (but only for enumeration types) or if-then-else trees). * The Common Block Optimization on Cmm happens later in the pipeline, making it non-trivial to detect branches that do the same thing. My plan is the following: * In the STG→Cmm transformation, floats will be handled separately. Matching against literals literals is fishy anyways, so my suggestion is to simply generate a linear list of equality checks here – turning the intended operation (equality test) into something else (comparisons in a if-then-else tree) feels wrong to me for floats. And the rest would not work well for floats, so I’d like to have them out of the way. * The case of enumeration types will be reduced to word literals, and treated the same from now on. * For integer types, no code generation decisions is made at this point. Instead, always a `CmmSwitch` statement is generated. * In a separate Cmm transformation pass, which will run /after/ the common block optimization, we visit all `CmmSwitches` and create proper code for them. I’d like to separate the algorithm that plans the code generation into a function (possibly even module) of its own, so that the decisions can easily by analyized and modified. The algorithm has a few choices to make: * If multiple values point to the same code, we can generate branchless code (`y := x == 1 || x == 5 || x = 7; if (y==0) then goto l1 else goto l2`). * If there are whole ranges pointing to the same code, the above can also use comparisons. * If there are dense ranges (i.e. a range with more than half of the possible values mapped to something), we want to generate jump tables from them (still `CmmSwitch` values). * Unless all options are handled by one of these possibilities, they need to be combined using `if-then-else` trees. The `CmmSwitch` constructor needs to change for that. It currently takes a `[Maybe Label]` argument, which is not suitable for before that pass, when its table may be sparse. I think an `IntMap Label` would work nicely. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10137> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #11459: Rather terrible error message due to excessive kind polymorphism
by GHC 21 Jan '16

21 Jan '16

#11459: Rather terrible error message due to excessive kind polymorphism -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When fixing up `cassava` for GHC 8.0 I found I needed to enable `PolyKinds` due to an unrelated change encountered a rather vexing error. Consider this, {{{#!hs {-# LANGUAGE DataKinds, PolyKinds, KindSignatures, RankNTypes #-} module Hi where -- | Failure continuation. type Failure f r = String -> f r -- | Success continuation. type Success a f r = a -> f r newtype Parser a = Parser { unParser :: forall f r. Failure f r -> Success a f r -> f r } runParser :: Parser a -> Either String a runParser p = unParser p left right where left !errMsg = Left errMsg right !x = Right x }}} With GHC 7.10 this failed with the quite comprehensible, {{{ Hi.hs:21:20: A newtype constructor cannot have existential type variables Parser :: forall a (k :: BOX). (forall (f :: k -> *) (r :: k). Failure f r -> Success a f r -> f r) -> Parser a In the definition of data constructor ‘Parser’ In the newtype declaration for ‘Parser’ }}} However, with 8.0 the compiler curtly informs you that, {{{ Hi.hs:29:26: error: • Couldn't match kind ‘GHC.Prim.Any’ with ‘*’ When matching the kind of ‘Either String’ • In the second argument of ‘unParser’, namely ‘left’ In the expression: unParser p left right In an equation for ‘runParser’: runParser p = unParser p left right where left !errMsg = Left errMsg right !x = Right x }}} As expected, adding a kind signature to `Parser`'s type variables fixed the issue but the error doesn't help the user realize this nearly as much as it could. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11459> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #11266: Can't :browse some modules with GHCi 7.11
by GHC 21 Jan '16

21 Jan '16

#11266: Can't :browse some modules with GHCi 7.11 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: GHCi | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHCi crash Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Trying to `:browse` certain modules with GHCi fails with GHC 7.11: {{{ $ inplace/bin/ghc-stage2 --interactive GHCi, version 7.11.20151219: http://www.haskell.org/ghc/ :? for help λ> :browse GHC.Base ($) :: forall (w :: GHC.Types.Levity) a (b :: TYPE w). (a -> b) -> a -> b ($!) :: (a -> b) -> a -> b <lots of output elided> data Ordering*** Exception: No match in record selector tyConTyVars λ> :browse GHC.Exts class GHC.Exts.IsList l where type family GHC.Exts.Item l Kind: * -> * GHC.Exts.fromList :: [GHC.Exts.Item l] -> l GHC.Exts.fromListN :: Int -> [GHC.Exts.Item l] -> l GHC.Exts.toList :: l -> [GHC.Exts.Item l] {-# MINIMAL fromList, toList #-} <lots of output elided> data GHC.Prim.MutableByteArray# a*** Exception: No match in record selector tyConTyVars λ> :browse GHC.Prim *** Exception: No match in record selector tyConTyVars }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11266> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #9357: Kind-polymorphic type family accepts unlifted type arguments
by GHC 21 Jan '16

21 Jan '16

#9357: Kind-polymorphic type family accepts unlifted type arguments -------------------------------------+------------------------------------- Reporter: kosmikus | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.2 checker) | Operating System: Keywords: | Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: GHC Difficulty: Unknown | accepts invalid program Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- The following code is accepted by ghc-7.8.2 and ghc-7.6.3: {{{#!hs {-# LANGUAGE TypeFamilies, MagicHash, PolyKinds #-} import GHC.Exts type family F (a :: k) :: * type instance F Int# = () }}} In nearly all other places, it seems that unlifted types are explicitly forbidden. I'm also not allowed to actually apply `F` to `Int#` after defining the type family like this. So I think the compiler should probably reject the `type instance`. (BTW, is it actually clear that using `#` as an argument kind to a type family or as an index kind for a GADT is in any way harmful?) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9357> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #11051: GHCi with +t option set shows type representations
by GHC 21 Jan '16

21 Jan '16

#11051: GHCi with +t option set shows type representations -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- hvr reported this morning that defining a data type in GHCi with the show types (`:set +t`) option set results in additional unexpected output. For instance, {{{ $ inplace/bin/ghc-stage2 --interactive GHCi, version 7.11.20151101: http://www.haskell.org/ghc/ :? for help Prelude> :set +t Prelude> data Hi $tcHi :: TyCon $trModule :: Module data Hi Prelude> }}} The `$tcHi` and `$trModule` bindings are details of the Typeable implementation introduced in Phab:D1404 and should likely be hidden from the user. This would be trivial to fix except for the fact that we currently have no way to identify this sort of `Name`. In fact any knowledge that the name was generated appears to have been thrown away as early as `OccName.mkTyConRepSysOcc`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11051> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 19

Re: [GHC] #3217: Make GHCi have separate flags for interactive Haskell expressions
by GHC 21 Jan '16

21 Jan '16

#3217: Make GHCi have separate flags for interactive Haskell expressions -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.10.2 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 3202 Related Tickets: #11469 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => duplicate * related: => #11469 Comment: Removed the milestone, for the statistics. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3217#comment:37> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #3217: Make GHCi have separate flags for interactive Haskell expressions
by GHC 21 Jan '16

21 Jan '16

#3217: Make GHCi have separate flags for interactive Haskell expressions -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 3202 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: closed => new * resolution: fixed => * milestone: 8.0.1 => -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3217#comment:36> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0