November 2015 - ghc-tickets

[GHC] #11111: error message for ":show" in GHCi does not show "paths"
by GHC 29 Nov '15

29 Nov '15

1 6

Re: [GHC] #8004: Applicative/Monad proposal related warnings (AMP phase 1)
by GHC 29 Nov '15

29 Nov '15

#8004: Applicative/Monad proposal related warnings (AMP phase 1) -------------------------------------+------------------------------------- Reporter: quchen | Owner: quchen Type: feature request | Status: closed Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #4834 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari <ben@…>): In [changeset:"290def72f54db7969258b4541aaefc87b54ce448/ghc" 290def72/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="290def72f54db7969258b4541aaefc87b54ce448" Implement warnings for Semigroups as parent of Monoid This patch is similar to the AMP patch (#8004), which offered two functions: 1. Warn when an instance of a class has been given, but the type does not have a certain superclass instance 2. Warn when top-level definitions conflict with future Prelude names These warnings are issued as part of the new `-Wcompat` warning group. Reviewers: hvr, ekmett, austin, bgamari Reviewed By: hvr, ekmett, bgamari Subscribers: ekmett, thomie Differential Revision: https://phabricator.haskell.org/D1539 GHC Trac Issues: #11139 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8004#comment:25> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #11132: Remove deprecated quasiquote syntax
by GHC 29 Nov '15

29 Nov '15

#11132: Remove deprecated quasiquote syntax -------------------------------------+------------------------------------- Reporter: mpickering | Owner: mpickering Type: task | Status: new 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: Differential Rev(s): Phab:D1530 | Wiki Page: -------------------------------------+------------------------------------- The [$qq| quasiquote syntax has been deprecated since around 2010. I counted 216 uses of it on hackage in a handful of packages, some in comments. http://lpaste.net/145938 Here is the commit which deprecated it - https://github.com/ghc/ghc/commit/9ba922ee06b048774d7a82964867ff768a78126e Mailing list thread - https://mail.haskell.org/pipermail/ghc- devs/2015-November/010573.html -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11132> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #11130: GHCi should not defer typed holes
by GHC 29 Nov '15

29 Nov '15

#11130: GHCi should not defer typed holes -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: GHCi | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | warning at compile-time Test Case: | Blocked By: ghci/scripts/T10248 | Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In the function `tcUserStmt` in compiler/typecheck/TcRnDriver.hs, before going over the different ways ('plans') to lift an expression typed at the prompt into the GHCi monad, `Opt_DeferTypeErrors` is disabled. Here is the accompanying comment: {{{ -- Ensure that type errors don't get deferred when type checking the -- naked expression. Deferring type errors here is unhelpful because the -- expression gets evaluated right away anyway. It also would potentially -- emit redundant type-error warnings, one from each plan. ; plan <- unsetGOptM Opt_DeferTypeErrors $ }}} Since `Opt_DeferTypeErrors` implies `Opt_DeferTypedHoles`, `Opt_DeferTypedHoles` should be disabled here as well. This will improve the error message for T10248. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11130> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

Re: [GHC] #1262: RecursiveDo in Template Haskell
by GHC 29 Nov '15

29 Nov '15

#1262: RecursiveDo in Template Haskell -------------------------------------+------------------------------------- Reporter: philip.weaver@… | Owner: Type: feature request | Status: new Priority: normal | Milestone: ⊥ Component: Template Haskell | Version: 6.6 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by massysett): * cc: massysett (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1262#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7478: setSessionDynFlags does not always work
by GHC 29 Nov '15

29 Nov '15

#7478: setSessionDynFlags does not always work -------------------------------------+------------------------------------- Reporter: edsko | Owner: bherzog Type: bug | Status: closed Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: ghc-api/T7478 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1017 Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): As a data point, I just ran into this because T7478 unexpectedly passes on my Mac. So perhaps the test should be updated... but I have no idea about this end of the operation. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7478#comment:24> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2940: Do CSE after CorePrep
by GHC 28 Nov '15

28 Nov '15

#2940: Do CSE after CorePrep -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: lowest | Milestone: 8.0.1 Component: Compiler | Version: 6.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): Simon, I was experimenting with CSE and unless I'm missing something I think current CSE is basically useless and we can just remove it. As far as I understand from the implementation, current CSE implementation never introduces a let binding. So for example if I have something like: {{{#!haskell g x = (x + 1, x + 1) }}} Current implementation never does CSE here. What's worse is that even if I have a let binding like this: {{{#!haskell g x = let x_1 = x + 1 in (x_1, x + 1) }}} Most of the time CSE can't do anything, because some other pass inlines/unfolds `x_1` here(even with -O0). `g` above is compiled to this: {{{#!haskell g :: Int -> (Int, Int) g = \ (x_atS :: Int) -> (case x_atS of _ { I# x_a1IL -> I# (+# x_a1IL 1#) }, case x_atS of _ { I# x_a1IL -> I# (+# x_a1IL 1#) }) }}} See how let binding is removed. CSE can't do anything here. Funny thing is even if I mark this let binding as `NOINLINE` CSE can't work, because of Note [CSE for INLINE and NOINLINE]. This is what happens when I mark `x_1` as `NOINLINE`: {{{#!haskell g' :: Int -> (Int, Int) g' = \ (x_av2 :: Int) -> let { x_1_s1Jd :: Int x_1_s1Jd = case x_av2 of _ { I# x_a1IL -> I# (+# x_a1IL 1#) } } in (case x_av2 of _ { I# x_a1IL -> I# (+# x_a1IL 1#) }, x_1_s1Jd) }}} There's a clear CSE opportunity missed because of Note [CSE for INLINE and NOINLINE]. So unless we actually run this after `CorePrep` it just can't do anything. I tried on a couple of examples and it seems like current CSE implementation actually maintains invariants at least some of the time. For example, it works find on the code in the code above. Do we have something like `CoreLint` but fore `CorePrep` invariants? ---- In the examples I tried CSE never worked before the `CorePrep` step. After `CorePrep` it worked some of the time. For example, `g` above is compiled to this: {{{#!haskell -- RHS size: {terms: 17, types: 8, coercions: 0} g :: Int -> (Int, Int) g = \ (x_s2nV :: Int) -> let { sat_s2o3 :: Int sat_s2o3 = case x_s2nV of wild_s2o0 { I# x1_s2o1 -> case +# x1_s2o1 1# of sat_s2o2 { __DEFAULT -> I# sat_s2o2 } } } in let { sat_s2nZ :: Int sat_s2nZ = sat_s2o3 } in (sat_s2o3, sat_s2o3) }}} `h` also CSEs nicely if we run it after `CorePrep`: {{{#!haskell -- RHS size: {terms: 23, types: 8, coercions: 0} h :: Int# -> (Int, Int) h = \ (x_s2nq :: Int#) -> case +# x_s2nq 1# of sat_s2nt { __DEFAULT -> case *# sat_s2nt 2# of sat_s2nu { __DEFAULT -> let { sat_s2nv :: Int sat_s2nv = I# sat_s2nu } in case sat_s2nt of sat_s2nr { __DEFAULT -> let { sat_s2ns :: Int sat_s2ns = I# sat_s2nt } in (sat_s2ns, sat_s2nv) } } } }}} It doesn't work on `rev`, because of how `CorePrep` generates a program without any CSE opportunity: {{{#!haskell -- RHS size: {terms: 23, types: 19, coercions: 0} Main.rev :: [GHC.Types.Bool] -> [GHC.Types.Bool] Main.rev = \ (xs_s2nl :: [GHC.Types.Bool]) -> let { sat_s2np :: [GHC.Types.Bool] sat_s2np = case GHC.List.reverse1 @ GHC.Types.Bool xs_s2nl (GHC.Types.[] @ GHC.Types.Bool) of sat_s2no { __DEFAULT -> GHC.List.filter @ GHC.Types.Bool (GHC.Base.id @ GHC.Types.Bool) sat_s2no } } in case GHC.List.reverse1 @ GHC.Types.Bool xs_s2nl (GHC.Types.[] @ GHC.Types.Bool) of sat_s2nm { __DEFAULT -> case GHC.List.reverse1 @ GHC.Types.Bool sat_s2nm (GHC.Types.[] @ GHC.Types.Bool) of sat_s2nn { __DEFAULT -> GHC.Base.++ @ GHC.Types.Bool sat_s2nn sat_s2np } } }}} Ideally we'd like to generate a binding for `GHC.List.reverse1 @ GHC.Types.Bool xs_s2nl (GHC.Types.[] @ GHC.Types.Bool)` but since this expression is not bound to a let-binder we can't CSE. (This would work if had the invariant of having only variables(and literals) in scrutinee position) For the record, this is what's generated by CSE after `CorePrep`: {{{#!haskell rev :: [Bool] -> [Bool] rev = \ (xs_s2nl :: [Bool]) -> let { sat_s2np :: [Bool] sat_s2np = case reverse1 @ Bool xs_s2nl ([] @ Bool) of sat_s2no { __DEFAULT -> filter @ Bool (id @ Bool) sat_s2no } } in case reverse1 @ Bool xs_s2nl ([] @ Bool) of sat_s2nm { __DEFAULT -> case reverse1 @ Bool sat_s2nm ([] @ Bool) of sat_s2nn { __DEFAULT -> ++ @ Bool sat_s2nn sat_s2np } } }}} ---- I want to work on running CSE after CorePrep, but before that I'm planning implementing a CoreLint-like pass for checking CorePrep invariants. Simon, does that make sense? Any ideas? Am I missing anything in my observations? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2940#comment:17> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10836: Better error reporting for closed type families
by GHC 28 Nov '15

28 Nov '15

#10836: Better error reporting for closed type families -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Consider this code: {{{#!hs {-# LANGUAGE TypeFamilies #-} module Bug where type family Foo a = r | r -> a type instance Foo Int = Int type instance Foo Bool = Int type family Bar a = r | r -> a type instance Bar Int = Int type instance Bar Bool = Int }}} Both definitions are incorrect as they violate their injectivity annotation. When I compile the module GHC reports errors on both definitons: {{{ Bug.hs:9:15: error: Type family equations violate injectivity annotation: Foo Bool = Int Foo Int = Int Bug.hs:13:15: error: Type family equations violate injectivity annotation: Bar Bool = Int Bar Int = Int }}} When I convert these to closed type families: {{{#!hs {-# LANGUAGE TypeFamilies #-} module Bug where type family Foo a = r | r -> a where Foo Int = Int Foo Bool = Int type family Bar a = r | r -> a where Bar Int = Int Bar Bool = Int }}} GHC only reports error on `Foo` but not on `Bar`: {{{ Bug.hs:8:5: error: Type family equations violate injectivity annotation: Foo Int = Int Foo Bool = Int In the equations for closed type family ‘Foo’ In the type family declaration for ‘Foo’ }}} Only when I fix the error on `Foo` I get the error on `Bar`. This is mostly annoying. A spectacular example of when this is really a problem can be seen in the testsuite: for open type families all the failing injectivity tests are in one test `T6018fail` but for closed type families there are twelve separate tests (`T6018closedfail01` through `T6018closedfail12`). I pinned down the problem to these lines in `TcTyClsDecls.tcTyClGroup`: {{{#!hs ; checkNoErrs $ mapM_ (recoverM (return ()) . checkValidTyCl) tyclss -- We recover, which allows us to report multiple validity errors -- the checkNoErrs is necessary to fix #7175. }}} As stated by the comment, removing `checkNoErrs` fixes the problem but breaks #7175. Commit message for d0ddde58f928a6b156d8061c406226c4fbb7cd22 suggests that this can't be easily fixed. Richard Eisenberg also remarks: "It's all about the irrefutable pattern in `rejigConRes` for matching up result types of GADTs." -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10836> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #11141: Better error message when instance signature is incorrect
by GHC 27 Nov '15

27 Nov '15

#11141: Better error message when instance signature is incorrect -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Documentation Unknown/Multiple | bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I was recently trying to solve an ambiguity error in a type class instance I was writing, and ended up with some code that looked like this (the ambiguity error has been eliminated for simplicity): {{{ {-# LANGUAGE FunctionalDependencies #-} {-# LANGUAGE InstanceSigs #-} {-# LANGUAGE ScopedTypeVariables #-} module A where data F a = F a instance Show a => Show (F a) where show :: forall a. Show a => F a -> String show (F x) = show x }}} This instance signature is incorrect: it's not necessary to add a universal quantifier to scope over type variables defined in the instance head; they are automatically in scope. But GHC unhelpfully reports: {{{ ezyang@sabre:~$ Dev/ghc-7.10.2/usr/bin/ghci A.hs GHCi, version 7.10.2: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling A ( A.hs, interpreted ) A.hs:8:13: Could not deduce (Show a0) from the context (Show a) bound by the type signature for show :: Show a => F a -> String at A.hs:8:13-45 The type variable ‘a0’ is ambiguous When checking that: forall a. Show a => forall a1. Show a1 => F a1 -> String is more polymorphic than: forall a. Show a => F a -> String When checking that instance signature for ‘show’ is more general than its signature in the class Instance sig: forall a. Show a => forall a1. Show a1 => F a1 -> String Class sig: forall a. Show a => F a -> String In the instance declaration for ‘Show (F a)’ Failed, modules loaded: none. }}} Why did I get the wrong idea about how instance signatures work? Well, GHC doesn't warn if you write this: {{{ instance Show a => Show (F a) where show :: Show a => F a -> String show (F x) = show x }}} Because this turns into a full type signature 'Show a, Show a => F a -> String' (the first a and the second a end up getting unified.) I'm not sure if it should warn; it's an easy mistake to make if you are treating instance methods like plain function definitions (of course you have to write the full type signature...) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11141> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #11136: Associated type family: panic due to mismatch in arity of default instances
by GHC 27 Nov '15

27 Nov '15

#11136: Associated type family: panic due to mismatch in arity of default instances -------------------------------------+------------------------------------- Reporter: airini | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Having extra type parameters in the definition of default instances for an associated type family causes a ghc panic error (should be detected as a not valid instance). Smallest case example: {{{#!hs class C a where type D a type instance D a x = x }}} It produces the error: {{{ [1 of 1] Compiling Main ( SplitKindFun.hs, interpreted ) ghc: panic! (the 'impossible' happened) (GHC version 7.10.2 for x86_64-apple-darwin): splitKindFunTysN 1 * Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Crashes similarly for additional parameters in the default instance: {{{#!hs class C a where type D a type instance D a x y = x }}} {{{ [1 of 1] Compiling Main ( SplitKindFun.hs, interpreted ) ghc: panic! (the 'impossible' happened) (GHC version 7.10.2 for x86_64-apple-darwin): splitKindFunTysN 2 * Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Presumably the arity is not compared correctly to that of the family declaration when the kind is default `*` since the following (and equivalent) causes the panic crash: {{{#!hs class C a where type D a :: * type instance D a x = x }}} but increasing the arity of the family's kind {{{#!hs class C a where type D a :: * -> * type instance D a x = x }}} raises the appropriate error: {{{ [1 of 1] Compiling Main ( SplitKindFun.hs, interpreted ) SplitKindFun.hs:6:3: Number of parameters must match family declaration; expected 1 In the default type instance declaration for ‘D’ In the class declaration for ‘C’ Failed, modules loaded: none. }}} Longer verbose compiler output of the original error: {{{ $ ghc -v SplitKindFun.hs Glasgow Haskell Compiler, Version 7.10.2, stage 2 booted by GHC version 7.10.1.20150612 Using binary package database: /Library/Frameworks/GHC.framework/Versions/7.10.2-x86_64/usr/lib/ghc-7.10.2/package.conf.d/package.cache Using binary package database: /Users/uu/.ghc/x86_64-darwin-7.10.2/package.conf.d/package.cache wired-in package ghc-prim mapped to ghc- prim-0.4.0.0-af16264bc80979d06e37ac63e3ba9a21 wired-in package integer-gmp mapped to integer- gmp-1.0.0.0-8e0f14d0262184533b417ca1f8b44482 wired-in package base mapped to base-4.8.1.0-075aa0db10075facc5aaa59a7991ca2f wired-in package rts mapped to builtin_rts wired-in package template-haskell mapped to template- haskell-2.10.0.0-161ca39a5ae657ff216d049e722e60ea wired-in package ghc mapped to ghc-7.10.2-5c2381785a7b22838c6eda985bc898cf wired-in package dph-seq not found. wired-in package dph-par not found. Hsc static flags: wired-in package ghc-prim mapped to ghc- prim-0.4.0.0-af16264bc80979d06e37ac63e3ba9a21 wired-in package integer-gmp mapped to integer- gmp-1.0.0.0-8e0f14d0262184533b417ca1f8b44482 wired-in package base mapped to base-4.8.1.0-075aa0db10075facc5aaa59a7991ca2f wired-in package rts mapped to builtin_rts wired-in package template-haskell mapped to template- haskell-2.10.0.0-161ca39a5ae657ff216d049e722e60ea wired-in package ghc mapped to ghc-7.10.2-5c2381785a7b22838c6eda985bc898cf wired-in package dph-seq not found. wired-in package dph-par not found. *** Chasing dependencies: Chasing modules from: *SplitKindFun.hs Stable obj: [] Stable BCO: [] Ready for upsweep [NONREC ModSummary { ms_hs_date = 2015-11-26 15:20:15 UTC ms_mod = Main, ms_textual_imps = [import (implicit) Prelude] ms_srcimps = [] }] *** Deleting temp files: Deleting: compile: input file SplitKindFun.hs Created temporary directory: /var/folders/m3/cx6_zbks6qq2xtwx92njp8w40000gn/T/ghc755_0 *** Checking old interface for Main: [1 of 1] Compiling Main ( SplitKindFun.hs, SplitKindFun.o ) *** Parser: *** Renamer/typechecker: *** Deleting temp files: Deleting: /var/folders/m3/cx6_zbks6qq2xtwx92njp8w40000gn/T/ghc755_0/ghc_1.s Warning: deleting non-existent /var/folders/m3/cx6_zbks6qq2xtwx92njp8w40000gn/T/ghc755_0/ghc_1.s *** Deleting temp dirs: Deleting: /var/folders/m3/cx6_zbks6qq2xtwx92njp8w40000gn/T/ghc755_0 ghc: panic! (the 'impossible' happened) (GHC version 7.10.2 for x86_64-apple-darwin): splitKindFunTysN 1 * Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11136> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3