March 2013 - ghc-tickets

Re: [GHC] #5333: Arrow command combinators and infixr cause the desugarer to fail
by GHC 04 Mar '13

04 Mar '13

#5333: Arrow command combinators and infixr cause the desugarer to fail ----------------------------------+----------------------------------------- Reporter: peteg | Owner: ross Type: bug | Status: new Priority: low | Milestone: 7.6.2 Component: Compiler (Parser) | Version: 7.0.3 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: GHC rejects valid program Difficulty: | Testcase: Blockedby: | Blocking: ----------------------------------+----------------------------------------- Comment(by simonpj@…): commit c3ad38d7dc39ef583ddfb586413baa2e57ca3ee8 {{{ Author: Simon Peyton Jones <simonpj(a)microsoft.com> Date: Mon Mar 4 09:40:56 2013 +0000 Rearrange the typechecking of arrows, especially arrow "forms" The typechecking of arrow forms (in GHC 7.6) is known to be bogus, as described in Trac #5609, because it marches down tuple types that may not yet be fully worked out, depending on when constraint solving happens. Moreover, coercions are generated and simply discarded. The fact that it works at all is a miracle. This refactoring is based on a conversation with Ross, where we rearranged the typing of the argument stack, so that the arrows have the form a (env, (arg1, (arg2, ...(argn, ())))) res rather than a (arg1, (arg2, ...(argn, env))) res as it was before. This is vastly simpler to typecheck; just look at the beautiful, simple type checking of arrow forms now! We need a new HsCmdCast to capture the coercions generated from the argument stack. This leaves us in a better position to tackle the open arrow tickets * Trac #5777 still fails. (I was hoping this patch would cure it.) * Trac #5609 is too complicated for me to grok. Ross? * Trac #344 * Trac #5333 compiler/deSugar/Coverage.lhs | 3 + compiler/deSugar/DsArrows.lhs | 486 +++++++++++++++++++++---------------- compiler/hsSyn/HsExpr.lhs | 13 +- compiler/hsSyn/HsUtils.lhs | 7 +- compiler/parser/Parser.y.pp | 4 +- compiler/parser/RdrHsSyn.lhs | 4 +- compiler/rename/RnExpr.lhs | 4 +- compiler/rename/RnTypes.lhs | 2 +- compiler/typecheck/TcArrows.lhs | 272 ++++++++++----------- compiler/typecheck/TcHsSyn.lhs | 6 +- docs/users_guide/glasgow_exts.xml | 48 +++-- 11 files changed, 461 insertions(+), 388 deletions(-) }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5333#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #344: arrow notation: incorrect scope of existential dictionaries
by GHC 04 Mar '13

04 Mar '13

#344: arrow notation: incorrect scope of existential dictionaries --------------------------------------+------------------------------------- Reporter: nobody | Owner: ross Type: bug | Status: new Priority: lowest | Milestone: 7.6.2 Component: Compiler (Type checker) | Version: 6.4 Resolution: None | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Compile-time crash | Difficulty: Unknown Testcase: | Blockedby: Blocking: | Related: --------------------------------------+------------------------------------- Comment(by simonpj@…): commit c3ad38d7dc39ef583ddfb586413baa2e57ca3ee8 {{{ Author: Simon Peyton Jones <simonpj(a)microsoft.com> Date: Mon Mar 4 09:40:56 2013 +0000 Rearrange the typechecking of arrows, especially arrow "forms" The typechecking of arrow forms (in GHC 7.6) is known to be bogus, as described in Trac #5609, because it marches down tuple types that may not yet be fully worked out, depending on when constraint solving happens. Moreover, coercions are generated and simply discarded. The fact that it works at all is a miracle. This refactoring is based on a conversation with Ross, where we rearranged the typing of the argument stack, so that the arrows have the form a (env, (arg1, (arg2, ...(argn, ())))) res rather than a (arg1, (arg2, ...(argn, env))) res as it was before. This is vastly simpler to typecheck; just look at the beautiful, simple type checking of arrow forms now! We need a new HsCmdCast to capture the coercions generated from the argument stack. This leaves us in a better position to tackle the open arrow tickets * Trac #5777 still fails. (I was hoping this patch would cure it.) * Trac #5609 is too complicated for me to grok. Ross? * Trac #344 * Trac #5333 compiler/deSugar/Coverage.lhs | 3 + compiler/deSugar/DsArrows.lhs | 486 +++++++++++++++++++++---------------- compiler/hsSyn/HsExpr.lhs | 13 +- compiler/hsSyn/HsUtils.lhs | 7 +- compiler/parser/Parser.y.pp | 4 +- compiler/parser/RdrHsSyn.lhs | 4 +- compiler/rename/RnExpr.lhs | 4 +- compiler/rename/RnTypes.lhs | 2 +- compiler/typecheck/TcArrows.lhs | 272 ++++++++++----------- compiler/typecheck/TcHsSyn.lhs | 6 +- docs/users_guide/glasgow_exts.xml | 48 +++-- 11 files changed, 461 insertions(+), 388 deletions(-) }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/344#comment:26> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5609: Type checking arrow notation in the presence of deferred constraints
by GHC 04 Mar '13

04 Mar '13

#5609: Type checking arrow notation in the presence of deferred constraints ----------------------------------------+----------------------------------- Reporter: dreixel | Owner: ross Type: bug | Status: new Priority: low | Milestone: 7.6.2 Component: Compiler (Type checker) | Version: 7.3 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: | Testcase: Blockedby: | Blocking: ----------------------------------------+----------------------------------- Comment(by simonpj@…): commit c3ad38d7dc39ef583ddfb586413baa2e57ca3ee8 {{{ Author: Simon Peyton Jones <simonpj(a)microsoft.com> Date: Mon Mar 4 09:40:56 2013 +0000 Rearrange the typechecking of arrows, especially arrow "forms" The typechecking of arrow forms (in GHC 7.6) is known to be bogus, as described in Trac #5609, because it marches down tuple types that may not yet be fully worked out, depending on when constraint solving happens. Moreover, coercions are generated and simply discarded. The fact that it works at all is a miracle. This refactoring is based on a conversation with Ross, where we rearranged the typing of the argument stack, so that the arrows have the form a (env, (arg1, (arg2, ...(argn, ())))) res rather than a (arg1, (arg2, ...(argn, env))) res as it was before. This is vastly simpler to typecheck; just look at the beautiful, simple type checking of arrow forms now! We need a new HsCmdCast to capture the coercions generated from the argument stack. This leaves us in a better position to tackle the open arrow tickets * Trac #5777 still fails. (I was hoping this patch would cure it.) * Trac #5609 is too complicated for me to grok. Ross? * Trac #344 * Trac #5333 compiler/deSugar/Coverage.lhs | 3 + compiler/deSugar/DsArrows.lhs | 486 +++++++++++++++++++++---------------- compiler/hsSyn/HsExpr.lhs | 13 +- compiler/hsSyn/HsUtils.lhs | 7 +- compiler/parser/Parser.y.pp | 4 +- compiler/parser/RdrHsSyn.lhs | 4 +- compiler/rename/RnExpr.lhs | 4 +- compiler/rename/RnTypes.lhs | 2 +- compiler/typecheck/TcArrows.lhs | 272 ++++++++++----------- compiler/typecheck/TcHsSyn.lhs | 6 +- docs/users_guide/glasgow_exts.xml | 48 +++-- 11 files changed, 461 insertions(+), 388 deletions(-) }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5609#comment:5> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5777: core lint error with arrow notation and GADTs
by GHC 04 Mar '13

04 Mar '13

#5777: core lint error with arrow notation and GADTs ---------------------------------+------------------------------------------ Reporter: benmos | Owner: ross Type: bug | Status: new Priority: normal | Milestone: 7.6.2 Component: Compiler | Version: 7.4.2 Keywords: arrows, GADTs | Os: MacOS X Architecture: Unknown/Multiple | Failure: Compile-time crash Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Comment(by simonpj@…): commit c3ad38d7dc39ef583ddfb586413baa2e57ca3ee8 {{{ Author: Simon Peyton Jones <simonpj(a)microsoft.com> Date: Mon Mar 4 09:40:56 2013 +0000 Rearrange the typechecking of arrows, especially arrow "forms" The typechecking of arrow forms (in GHC 7.6) is known to be bogus, as described in Trac #5609, because it marches down tuple types that may not yet be fully worked out, depending on when constraint solving happens. Moreover, coercions are generated and simply discarded. The fact that it works at all is a miracle. This refactoring is based on a conversation with Ross, where we rearranged the typing of the argument stack, so that the arrows have the form a (env, (arg1, (arg2, ...(argn, ())))) res rather than a (arg1, (arg2, ...(argn, env))) res as it was before. This is vastly simpler to typecheck; just look at the beautiful, simple type checking of arrow forms now! We need a new HsCmdCast to capture the coercions generated from the argument stack. This leaves us in a better position to tackle the open arrow tickets * Trac #5777 still fails. (I was hoping this patch would cure it.) * Trac #5609 is too complicated for me to grok. Ross? * Trac #344 * Trac #5333 compiler/deSugar/Coverage.lhs | 3 + compiler/deSugar/DsArrows.lhs | 486 +++++++++++++++++++++---------------- compiler/hsSyn/HsExpr.lhs | 13 +- compiler/hsSyn/HsUtils.lhs | 7 +- compiler/parser/Parser.y.pp | 4 +- compiler/parser/RdrHsSyn.lhs | 4 +- compiler/rename/RnExpr.lhs | 4 +- compiler/rename/RnTypes.lhs | 2 +- compiler/typecheck/TcArrows.lhs | 272 ++++++++++----------- compiler/typecheck/TcHsSyn.lhs | 6 +- docs/users_guide/glasgow_exts.xml | 48 +++-- 11 files changed, 461 insertions(+), 388 deletions(-) }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5777#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5014: canonicalizePath throws exception on paths that do not exist
by GHC 04 Mar '13

04 Mar '13

#5014: canonicalizePath throws exception on paths that do not exist ----------------------------------+----------------------------------------- Reporter: hesselink | Owner: Type: bug | Status: new Priority: low | Milestone: 7.6.2 Component: libraries/directory | Version: 7.0.2 Resolution: | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Runtime crash | Difficulty: Testcase: | Blockedby: Blocking: | Related: ----------------------------------+----------------------------------------- Changes (by dterei): * cc: dterei (added) Comment: Argh, this bug just bit me. Max, any chance of making that libraries proposal? Otherwise, Ian what is the correct documentation for this function? On OSX and Linux for me, non-existent paths throw an exception. Is that always the case or it varies from platforms? I think the documentation needs some warning about this. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5014#comment:12> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #910: --make should have a -j flag for parallel building
by GHC 03 Mar '13

03 Mar '13

#910: --make should have a -j flag for parallel building -------------------------------+-------------------------------------------- Reporter: igloo | Owner: Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.4.2 Resolution: | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Difficulty: Unknown Testcase: N/A | Blockedby: Blocking: | Related: -------------------------------+-------------------------------------------- Changes (by ihameed): * cc: idhameed@… (added) -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/910#comment:15> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #7696: Another kindFunResult panic
by GHC 03 Mar '13

03 Mar '13

#7696: Another kindFunResult panic -----------------------------+---------------------------------------------- Reporter: nwf | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.6.2 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- While working at the GHCi prompt, I left off a pair of parens, yielding: {{{ > import Control.Applicative > import Control.Monad.Trans > :type \x -> (either (fmap Right) id) <$> lift $ x ghc: panic! (the 'impossible' happened) (GHC version 7.7.20130214 for x86_64-unknown-linux): kindFunResult <<details unavailable>> Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Replacing `<$> lift $ x` with `<$> (lift $ x)`, which is what I'd meant, makes everybody happier. But as this happens in both 7.6.2 and 7.7.20130214, I thought I should do what it says and report it. Thanks! -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7696> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #7697: (=>) works on non-constraints
by GHC 03 Mar '13

03 Mar '13

#7697: (=>) works on non-constraints ----------------------------------------+----------------------------------- Reporter: monoidal | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.6.2 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: GHC accepts invalid program | Blockedby: Blocking: | Related: ----------------------------------------+----------------------------------- {{{ f :: Int => Int f = id }}} compiles in 7.6 and HEAD. It shouldn't? -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7697> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

Re: [GHC] #6135: Unboxed Booleans
by GHC 03 Mar '13

03 Mar '13

#6135: Unboxed Booleans ---------------------------------+------------------------------------------ Reporter: benl | Owner: jstolarek Type: feature request | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.4.1 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: #605 | ---------------------------------+------------------------------------------ Changes (by choenerzs): * cc: choener@… (added) -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/6135#comment:20> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #7734: Missing backticks in error message
by GHC 03 Mar '13

03 Mar '13

#7734: Missing backticks in error message ----------------------------------------------+----------------------------- Reporter: monoidal | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.6.2 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Incorrect warning at compile-time | Blockedby: Blocking: | Related: ----------------------------------------------+----------------------------- The code {{{ x `f` y = x x (&) x y = x x }}} gives errors with missing backticks and parentheses: {{{ A.hs:1:13: Occurs check: cannot construct the infinite type: t1 = t1 -> t0 In the first argument of `x', namely `x' In the expression: x x In an equation for `f': x f y = x x ^^^^^ A.hs:2:13: Occurs check: cannot construct the infinite type: t1 = t1 -> t0 In the first argument of `x', namely `x' In the expression: x x In an equation for `&': & x y = x x ^^^^^ }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7734> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3