December 2015 - ghc-tickets

[GHC] #9037: Add option to make selected warnings errors
by GHC 21 Jan '16

21 Jan '16

#9037: Add option to make selected warnings errors ------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- It would be great if GHC offered a `-ferror-*` flag for every `-fwarn-*` flag, that turns the given type of warning into an error. For example, I would like to always error on uninitialized record fields, but don't want to go full `-Werror`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9037> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[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] #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] #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] #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

[GHC] #9215: GHC 7.8.2 mingw-w64: symbol not found in link
by GHC 21 Jan '16

21 Jan '16

#9215: GHC 7.8.2 mingw-w64: symbol not found in link ------------------------------------+------------------------------------- Reporter: stuartallenmills | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- This includes calls such as strdup, stat, , and snprintf. These calls are not available in the 64 bit libraries (though 64 bit versions are such as _strdup, _snprintf) These problems have occurred in building yaml and unix-compat. They also occurred in system-fileio but jmilikin generated a patch for that library -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9215> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #11201: ghc --make on Haskell and non-Haskell inputs can silently clobber input
by GHC 20 Jan '16

20 Jan '16

#11201: ghc --make on Haskell and non-Haskell inputs can silently clobber input -------------------------------------+------------------------------------- Reporter: ezyang | 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: -------------------------------------+------------------------------------- Create any valid files A.hs and A.c, then run `ghc --make A.hs A.c`. You'll get one `A.o` file for `A.hs`; the `A.o` from `A.c` is lost to the sands of time. I thought this situation would be pretty unlikely but geekosaur mentioned to me that he had seen someone run into this problem before. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11201> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3