June 2014 - ghc-tickets

Re: [GHC] #7828: RebindableSyntax and Arrow
by GHC 12 Jun '14

12 Jun '14

#7828: RebindableSyntax and Arrow ----------------------------------------------+---------------------------- Reporter: AlessandroVermeulen | Owner: Type: bug | jstolarek Priority: normal | Status: new Component: Compiler (Type checker) | Milestone: 7.10.1 Resolution: | Version: 7.6.2 Operating System: Unknown/Multiple | Keywords: Type of failure: GHC rejects valid program | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: #1537, | #3613 ----------------------------------------------+---------------------------- Changes (by jstolarek): * related: => #1537, #3613 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7828#comment:25> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7828: RebindableSyntax and Arrow
by GHC 12 Jun '14

12 Jun '14

#7828: RebindableSyntax and Arrow ----------------------------------------------+---------------------------- Reporter: AlessandroVermeulen | Owner: Type: bug | jstolarek Priority: normal | Status: new Component: Compiler (Type checker) | Milestone: 7.10.1 Resolution: | Version: 7.6.2 Operating System: Unknown/Multiple | Keywords: Type of failure: GHC rejects valid program | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: Unknown | Blocked By: | Related Tickets: ----------------------------------------------+---------------------------- Comment (by jstolarek): In my work on the prototype I've ran into a problem I can't solve. Since desugaring of `HsCmdTop` [https://github.com/ghc/ghc/blob/165ac4af4a1002eff5f5a474bc21bc443c8f8c63/co… requires calls to arr and >>>] I've added two `SyntaxExpr` to `HsCmdTop` datatype. These two `SyntaxExpr`s [https://github.com/ghc/ghc/blob/165ac4af4a1002eff5f5a474bc21bc443c8f8c63/co… need to be typechecked in tcCmdTop]. I've see earlier how [https://github.com/ghc/ghc/blob/165ac4af4a1002eff5f5a474bc21bc443c8f8c63/co… typechecking of the do-notation bind is implemented] and decided to adopt a similar aproach: {{{ tcCmdTop env (L loc (HsCmdTop cmd _ _ names compose_op arr_op)) cmd_ty@(cmd_stk, res_ty) = setSrcSpan loc $ do { cmd' <- tcCmd env cmd cmd_ty ; names' <- mapM (tcSyntaxName ProcOrigin (cmd_arr env)) names -- VOODOO CODING based on typechecking of >>= in TcMatches -- is it correct to use b and c variables for typechecking in both -- arr and compose? ; a <- newFlexiTyVarTy liftedTypeKind ; b <- newFlexiTyVarTy liftedTypeKind ; c <- newFlexiTyVarTy liftedTypeKind ; arr_op' <- tcSyntaxOp DoOrigin arr_op (mkFunTy (mkFunTy b c) (mkCmdArrTy env b c)) ; compose_op' <- tcSyntaxOp DoOrigin compose_op (mkFunTys [mkCmdArrTy env a b, mkCmdArrTy env b c] (mkCmdArrTy env a c)) ; return (L loc $ HsCmdTop cmd' cmd_stk res_ty names' compose_op' arr_op') } }}} This however ends with a panic. Using `-dcore-lint` gives me this: {{{ *** Core Lint errors : in result of Desugar (after optimization) *** <no location info>: Warning: In the expression: T7828.>>> @ GHC.Prim.Any @ GHC.Prim.Any @ GHC.Prim.Any @ a_aEo @ (a_aEo, ()) @ a_aEo (T7828.arr @ GHC.Prim.Any @ GHC.Prim.Any @ a_aEo @ (a_aEo, ()) (\ (n_aus :: a_aEo) -> (n_aus, GHC.Tuple.()))) (T7828.>>> @ (a_aEo, ()) @ a_aEo @ a_aEo (T7828.arr @ (a_aEo, ()) @ a_aEo (\ (ds_dGU :: (a_aEo, ())) -> case ds_dGU of _ [Occ=Dead] { (ds_dGT, _ [Occ=Dead]) -> ds_dGT })) (T7828.returnA @ a_aEo)) Illegal type application: Exp type: T7828.R GHC.Prim.Any GHC.Prim.Any -> T7828.R GHC.Prim.Any GHC.Prim.Any -> T7828.R GHC.Prim.Any GHC.Prim.Any :: * Arg type: a_aEo :: * }}} These `GHC.Prim.Any` look wrong. Notice that there are two calls of `>>>` and `arr` but only one of each has these extra `GHC.Prim.Any` parameters. The incorrect `>>>` and `arr` are generated by my modified `HsCmdTop`. The other pair of `>>>` and `arr` is generated by `HsCmdArrApp` constructor, which has not been modified yet. Simon, help? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7828#comment:24> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #95: GHCi :edit command should jump to the the last error
by GHC 11 Jun '14

11 Jun '14

#95: GHCi :edit command should jump to the the last error -------------------------------+------------------------------------------- Reporter: | Owner: lortabac martijnislief | Status: patch Type: feature | Milestone: ⊥ request | Version: None Priority: normal | Keywords: Component: GHCi | Architecture: Unknown/Multiple Resolution: None | Difficulty: Easy (less than 1 hour) Operating System: | Blocked By: Unknown/Multiple | Related Tickets: Type of failure: | None/Unknown | Test Case: | Blocking: | -------------------------------+------------------------------------------- Comment (by lortabac): I added a `sameFile` function to check whether two paths point to the same file. However I can't find any readable alternative to: {{{ curFileErrs <- filterM (\(f, _) -> unpackFS f `sameFile` file) errs return $ case curFileErrs of (_, line):_ -> " +" ++ show line _ -> "" }}} As far as the test is concerned, I just followed the enumeration in the ghci directory, so I called it `prog013`. It would be nice to make it a bit more self-descriptive but I have no idea how. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/95#comment:20> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4934: threadWaitRead works incorrectly on nonthreaded RTS
by GHC 11 Jun '14

11 Jun '14

#4934: threadWaitRead works incorrectly on nonthreaded RTS ------------------------------------------------+-------------------------- Reporter: slyfox | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Runtime System | Version: 7.0.1 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Incorrect result at runtime | (amd64) Test Case: | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Comment (by Simon Peyton Jones <simonpj@…>): In [changeset:"7f467d0fbb1424f638a0d39caf57b9c0198421a8/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="7f467d0fbb1424f638a0d39caf57b9c0198421a8" Fix Windows build (wibble to fix for Trac #4934) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4934#comment:29> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9183: GHC shouldn't expand constraint synonyms
by GHC 11 Jun '14

11 Jun '14

#9183: GHC shouldn't expand constraint synonyms ------------------------------------+------------------------------------- Reporter: Feuerbach | 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: | ------------------------------------+------------------------------------- {{{ {-# LANGUAGE ConstraintKinds #-} type ShowX = Show showX :: ShowX a => a -> String showX = show }}} If I now ask for the type of showX, I get: {{{ *Main> :t showX showX :: Show a => a -> String }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9183> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #9097: Change GHC.Exts.Any to a type family
by GHC 11 Jun '14

11 Jun '14

#9097: Change GHC.Exts.Any to a type family ------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: task | 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: | ------------------------------------+------------------------------------- I just had this slightly alarming interchange with GHCi: {{{ Prelude> import Data.Type.Equality Prelude Data.Type.Equality> import GHC.Exts Prelude Data.Type.Equality GHC.Exts> :kind! ((Any :: Bool) == (Any :: Bool)) ((Any :: Bool) == (Any :: Bool)) :: Bool = 'False }}} After staring at the result in disbelief, I figured out why. The instance for `==` at kind `Bool` looks like this: {{{ type family EqBool a b where EqBool False False = True EqBool True True = True EqBool a b = False type instance (a :: Bool) == (b :: Bool) = EqBool a b }}} Well, `Any` isn't `False`, `Any` isn't `True`, so `Any == Any` must be `False`! The solution to this, of course, is to make `Any` a type family, not a datatype. Then, it wouldn't be apart from the equations in `EqBool`. I believe this idea has been floated previously but was not implemented as it would have disturbed !TypeLits and/or singletons. These libraries have been updated, and it's time. I'm happy to do this myself in due course. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9097> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

Re: [GHC] #7730: :info and polykinds
by GHC 11 Jun '14

11 Jun '14

#7730: :info and polykinds --------------------------------------------+------------------------------ Reporter: monoidal | Owner: archblob Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler (Type checker) | Version: 7.6.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #8776 --------------------------------------------+------------------------------ Changes (by archblob): * status: patch => closed * resolution: => fixed -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7730#comment:55> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9062: Role: ~# should be ~R#
by GHC 11 Jun '14

11 Jun '14

#9062: Role: ~# should be ~R# ------------------------------------+--------------------------------- Reporter: conal | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+--------------------------------- The following coercion showed up in Core. Richard Eisenberg pointed out that the `~#` should be `~R#`. {{{ <Tree N0 Int>_R -> NTCo:Sum[0] <Int>_R :: (Tree N0 Int -> Sum Int) ~# (Tree N0 Int -> Int) }}} I can dig up more information if needed. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9062> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #9167: Associated type is accepted even without mentioning class parameters
by GHC 11 Jun '14

11 Jun '14

#9167: Associated type is accepted even without mentioning class parameters ------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: low | 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: | ------------------------------------+------------------------------------- The following module is accepted: {{{ {-# LANGUAGE TypeFamilies #-} module Bug where class C a where type F b }}} Note that the associate type family `F` does not mention the class variable `a`. Because associated type families are somewhat thin sugar over non-associated type families, I doubt this causes any great disaster anywhere, but it should probably be fixed. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9167> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

Re: [GHC] #7673: Windows: run "git config --global core.autocrlf false" before cloning the repo
by GHC 11 Jun '14

11 Jun '14

#7673: Windows: run "git config --global core.autocrlf false" before cloning the repo -------------------------------+------------------------------------ Reporter: morabbin | Owner: hvr Type: bug | Status: new Priority: normal | Milestone: Component: Trac & Git | Version: Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------+------------------------------------ Changes (by thomie): * status: closed => new * cc: hvr (added) * component: Compiler => Trac & Git * version: 7.6.2 => * owner: => hvr * resolution: fixed => Comment: Running {{{./sync-all get}}} will now execute {{{'git reset --hard'}}} if core.autocrlf=true, which could result in data loss when uncommitted changes are present. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7673#comment:4> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0