January 2016 - ghc-tickets

Re: [GHC] #4248: Poor error message when openFile fails to open named pipe
by GHC 21 Jan '16

21 Jan '16

#4248: Poor error message when openFile fails to open named pipe -------------------------------------+--------------------------------- Reporter: Khudyakov | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.2.1 Component: libraries/base | Version: 6.12.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: -------------------------------------+--------------------------------- Comment (by Thomas Miedema <thomasmiedema@…>): In [changeset:"4c4a0a52d3ca5befd2a632544e9541703007e356/ghc" 4c4a0a5/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="4c4a0a52d3ca5befd2a632544e9541703007e356" Fix docstring GHC.IO.Handle.FD.openFileBLocking Fixes #4248. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4248#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #11172: Turning on optimisations produces Impossible case alternative
by GHC 21 Jan '16

21 Jan '16

#11172: Turning on optimisations produces Impossible case alternative -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime crash Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I believe I've found a bug that makes GHC generate the "Impossible case alternative" run-time crash with optimisations turned on (`-O`), which does not happen in ghci or without optimisations (`-O0`). Please see https://github.com/fpco/impossible-case-alternative-repro for a reproduction with GHC 7.10 and 7.8. What seems to happen here is that when `fun2` is inlined, the simplifier (or whatever component) decides that some `case` (I haven't figured out yet which one) is impossible; you can clearly see how it gets fixed in the Core when adding a `NOINLINE fun2` and compiling with `-ddump-simpl`. I believe this difference in inlining is also why `-O` makes a difference vs `-O0`. What certainly surprised me is that when replacing {{{ (do p <- earlyExit <* error "bad" return p) }}} with {{{ (earlyExit <* error "bad") }}} the error goes away as well. Note that I'm using some TemplateHaskell around that block; I'm wondering whether that somehow leads to an unfortunate interaction with the simpilifier. First thing I'd appreciate is somebody to tell me: Is this a real bug or something GHC allows itself to do? Since for most other run-time errors, GHC asks me to report a bug, but it doesn't do so for `Impossible case alternative`. I would have liked to make a smaller reproduction (currently it needs 2 files and aeson as an external depencency), but if I shrink it any further the error goes away. So for now I hope that a 150 line repro in 2 files will do. We have reproduced this on Linux and Mac, but I'm quite confident that it's platform-independent. I'm setting the milestone for this to 8.0.1 because this is a problem that makes some real-world trouble for us, feel free to change back if that's inappropriate. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11172> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 39

[GHC] #11479: GHC leaves GCC response files in /tmp
by GHC 21 Jan '16

21 Jan '16

#11479: GHC leaves GCC response files in /tmp -------------------------------------+------------------------------------- Reporter: tuncer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 | Type of failure: None/Unknown (amd64) | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- After building a random package with cabal, GHC leaves GCC response files in /tmp instead of deleting once done. Just in case, here's what such a file (/tmp/cc*) looks like: {{{ -plugin /usr/lib/gcc/x86_64-unknown-linux-gnu/5.3.0/liblto_plugin.so -plugin-opt=/usr/lib/gcc/x86_64-unknown-linux-gnu/5.3.0/lto-wrapper -plugin-opt=-fresolution=/tmp/ccwHAsFF.res -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lc -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s --build-id --eh-frame-hdr --hash-style=gnu -m elf_x86_64 -shared -o dist/dist-sandbox-58bccafc/build/libHSsplit-0.2.3-1yuUfUR0BKgqOQR1FQ3Jv- ghc7.10.3.so [...] }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11479> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[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