- ghc-tickets - Haskell.org

[GHC] #10896: BadSock triggers failing ASSERT
by GHC 02 Dec '15

02 Dec '15

#10896: BadSock triggers failing ASSERT -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- {{{ --- ./indexed-types/should_fail/BadSock.stderr.normalised 2015-09-18 20:44:48.437390831 +0000 +++ ./indexed-types/should_fail/BadSock.comp.stderr.normalised 2015-09-18 20:44:48.437390831 +0000 @@ -1,5 +1,5 @@ +ghc: panic! (the 'impossible' happened) + (GHC version 7.11.20150918 for x86_64-unknown-linux): + ASSERT failed! file compiler/typecheck/TcFlatten.hs, line 1041 -BadSock.hs:30:5: - The type family â€˜Readableâ€™ should have 1 argument, but has been given none - In the equations for closed type family â€˜Fooâ€™ - In the type family declaration for â€˜Fooâ€™ \ No newline at end of file +Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug \ No newline at end of file *** unexpected failure for BadSock(normal) }}} Haven't investigated any further. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10896> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #10839: Consistent pretty-printing of type families
by GHC 01 Dec '15

01 Dec '15

#10839: Consistent pretty-printing of type families -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 7.11 Keywords: newcomer | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Say I have this silly open type family declaration: {{{#!hs type family F a type instance F a = a type instance F a = Int }}} GHC complains: {{{ Foo.hs:8:15: error: Conflicting family instance declarations: F a -- Defined at Foo.hs:8:15 F a -- Defined at Foo.hs:9:15 }}} Now let's do some silliness with a closed type family: {{{#!hs type family F a where F a = a F a = Int }}} GHC warns: {{{ T6018.hs:9:5: warning: Type family instance equation is overlapped: F a = Int }}} Finally, some silliness with a kind-polymorphic type family: {{{#!hs type family Gc (a :: k) (b :: k) = r | r -> k where Gc a b = Int }}} GHC complains: {{{ T6018.hs:9:5: error: Type family equation violates injectivity annotation. Injective kind variable ‘k’ is not inferable from the RHS type variables. In the RHS of type family equation: forall (k :: BOX) (a :: k) (b :: k). Gc a b = Int In the equations for closed type family ‘Gc’ In the type family declaration for ‘Gc’ }}} There are some inconsistencies in pprinting of type family equations: * for open type families we print the location where the equation was defined but we do not print the RHS * for closed type families we print the RHS but we do not print the location in the source file * kind-polymorphic equations are not indented I would like to have a consistent pretty-printing of type family equations, one that prints the RHS, source code location and indents kind- polymorphic equations. The difference in pretty printing between open and closed type families comes from the difference between pprinting `CoAxBranch` and `FamInst`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10839> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

Re: [GHC] #7596: Opportunity to improve CSE
by GHC 01 Dec '15

01 Dec '15

#7596: Opportunity to improve CSE -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.6.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: | -------------------------------------+------------------------------------- Changes (by osa1): * cc: osa1 (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7596#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2940: Do CSE after CorePrep
by GHC 01 Dec '15

01 Dec '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 nomeata): Quite right. If one of us can now find the corresponding ticket, then we can continue there, and not hijack the discussion here :-)... there it is: #9291. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2940#comment:21> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2940: Do CSE after CorePrep
by GHC 01 Dec '15

01 Dec '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): Why do we need to do CSE in STG level to avoid allocation in `Either`s `fmap`? What does STG give us extra over Core? Do you mean not having type terms help? If so, how? {{{#!haskell -- RHS size: {terms: 14, types: 17, coercions: 0} Main.$fFunctorEither1_$cfmap :: forall a_aOH a1_avU b_avV. (a1_avU -> b_avV) -> Either1 a_aOH a1_avU -> Either1 a_aOH b_avV Main.$fFunctorEither1_$cfmap = \ (@ a_aOH) (@ a1_aOL) (@ b_aOM) (ds_dR3 :: a1_aOL -> b_aOM) (ds1_dR4 :: Either1 a_aOH a1_aOL) -> case ds1_dR4 of _ { Left1 x_avi -> Main.Left1 @ a_aOH @ b_aOM x_avi; Right1 y_avk -> Main.Right1 @ a_aOH @ b_aOM (ds_dR3 y_avk) } }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2940#comment:20> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2940: Do CSE after CorePrep
by GHC 01 Dec '15

01 Dec '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 nomeata): I did? Oh dear. It must have been before I started to dislike CSE very much, because it gets in the way of rules, and can creasing sharing (e.g. by cse’ing `[0..1000]`). Or maybe it was precisely when I startd to dislike CSE... :-) Speaking about the phases CSE should happen: I very much believe we need a CSE phase as an Stg-to-Stg-transformation, to avoid reallocating `Left`s in the code for a `Either`’s `fmap`, for example. (There is a ticket for this, cannot find it right now.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2940#comment:19> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2940: Do CSE after CorePrep
by GHC 01 Dec '15

01 Dec '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 simonpj): See [wiki:MoreCSE]. I'm inclined to think that it'd be better to do CSE ''earlier'' not ''later''. The main idea (on the [wiki:MoreCSE] page) is this: * Make float-out more aggressive by (a) let-binding every sub-expression, and (b) floating let-bindings out even if they don't escape a lambda. So in your first example {{{ g x = (x + 1, x + 1) }}} we'd get {{{ g x = let v1 = x+1 in let v2 = x+2 in (v1,v2) }}} * Now do CSE as now. The extra let-bindings should give a lot more more opportunities. * Float inwards to reverse the effect of the first pass if CSE did not bite. Also talk to Joachim who wrote [wiki:MoreCSE]. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2940#comment:18> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #11139: Add Semigroup warnings
by GHC 30 Nov '15

30 Nov '15

#11139: Add Semigroup warnings -------------------------------------+------------------------------------- Reporter: quchen | Owner: Type: task | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 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: -------------------------------------+------------------------------------- Similar to #8004, do the following for Semigroup/Monoid: 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 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11139> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

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

30 Nov '15

1 6

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

30 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