- ghc-tickets - Haskell.org

Re: [GHC] #4114: Add a flag to remove/delete intermediate files generated by GHC
by GHC 20 Mar '16

20 Mar '16

#4114: Add a flag to remove/delete intermediate files generated by GHC -------------------------------------+------------------------------------- Reporter: guest | Owner: kaiha Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.10.4 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #2258 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by kaiha): * owner: => kaiha -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4114#comment:23> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #1012: ghc panic with mutually recursive modules and template haskell
by GHC 19 Mar '16

19 Mar '16

#1012: ghc panic with mutually recursive modules and template haskell -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: lowest | Milestone: Component: Template Haskell | Version: 6.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | TH_import_loop Blocked By: | Blocking: Related Tickets: #9032 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mgsloan): * cc: mgsloan (added) Comment: I just ran into this as well. There is a fairly generic usecase that requires this: defining TH that generates instances of a class, and then using that TH to generate non-orphan instances. Pretty much the same as the usecase Richard outlines above. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1012#comment:40> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #11718: Disable the Preview button on trac
by GHC 18 Mar '16

18 Mar '16

#11718: Disable the Preview button on trac -------------------------------------+------------------------------------- Reporter: nomeata | Owner: hvr Type: feature | Status: new request | Priority: normal | Milestone: Component: Trac & Git | 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: -------------------------------------+------------------------------------- More than once, I lost comments to track. My current hypothesis is that I accidentally clicked “Preview” instead of “Send changes” and closed the tab or browser afterwards, without noticing that I did not actually submit them. With the live preview, the Preview button is not as useful as it could be anyways. So maybe simply removing that button would do more good than harm. Erikd +1ed my request on IRC. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11718> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #11542: Profiling call count frequently 0 when it shouldn't be
by GHC 18 Mar '16

18 Mar '16

#11542: Profiling call count frequently 0 when it shouldn't be -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 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: -------------------------------------+------------------------------------- Here's an example (lines shortened): {{{ FUNCTION MODULE CALLS addinMTypeM Cortex.Stem.Exp.Addin 212462 56309 0.0 0.0 0.1 0.0 addinMTypeM'' Cortex.Stem.Exp.Addin 212463 0 0.0 0.0 0.1 0.0 memoize Cortex.Utils.Memo 212464 0 0.0 0.0 0.1 0.0 memoizeIO Cortex.Utils.Memo 212465 0 0.0 0.0 0.1 0.0 addinMTypeM' Cortex.Stem.Exp.Addin 212467 13799 0.0 0.0 0.1 0.0 }}} Maybe I don't understand the profile info, but here is my interpretation. addinMTypeM is called 56309 times, and then it calls addinMTypeM'' 0 times, which calls memoize 0 times, which calls memoizeIO 0 times, which calls addinMType' 13799. How can a function that was called 0 times call another function 13799 times? My profile are full of the 0 entries. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11542> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #10075: Muddling Constraint and * means that Core is inconsistent
by GHC 18 Mar '16

18 Mar '16

#10075: Muddling Constraint and * means that Core is inconsistent -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- I can say this: {{{ type family F (a :: k) type instance F (a :: Constraint) = Int type instance F (a :: *) = Bool }}} This compiles to the following Core: {{{ F :: forall (k :: BOX). k -> * axF1 :: [a :: Constraint].F Constraint a ~ Int axF2 :: [a :: *]. F * a ~ Bool }}} I can then build the following: {{{ sym axF1[Any Constraint] ; axF2[Any *] :: Int ~ Bool }}} The transitivity is sound because, in Core, `Constraint` and `*` are indistinguishable. I don't think there's a way to actually cause a bug in a running program due to this problem, but we should probably patch it up. Possible resolution: Have `coreView` change `Constraint` to `*`. Possible resolution once we have `* :: *`: Make `Constraint` and `*` representationally equal. In other words, it would be as if `Constraint` were a newtype around `*`. I haven't thought out the ramifications of this decision, but there's something nice about it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10075> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #11713: STM Finalizers
by GHC 17 Mar '16

17 Mar '16

#11713: STM Finalizers -------------------------------------+------------------------------------- Reporter: mc.schroeder | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Runtime | Version: 8.1 System | 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: -------------------------------------+------------------------------------- This is some work I did as part of my master's thesis [1]. It's an extension to GHC's STM implementation. The main idea is to introduce a new primitive function {{{#!hs atomicallyWithIO :: STM a -> (a -> IO b) -> IO b }}} Like the existing atomically operation, atomicallyWithIO performs an STM computation. Additionally, it takes a '''finalizer''', which is an arbitrary I/O action that can depend on the result of the STM computation, and combines it with the transaction in such a way that: 1. The finalizer is only performed if the STM transaction is guaranteed to commit. 2. The STM transaction only commits if the finalizer finishes without raising an exception. A detailed specification, including an operational semantics, as well as a discussion of the implementation, can be found in chapter 2 of my thesis [1]. ---- I actually did this work quite some time ago, and even announced it on the mailing list [2] to some positive feedback, but then never got around to actually submitting a patch. Last week Charles Strahan wrote me on GitHub and got me motivated again, so here I am :) I'm submitting a code review to Phabricator right now and will link it to this ticket. ---- [1] https://github.com/mcschroeder/thesis [2] https://mail.haskell.org/pipermail/haskell-cafe/2015-July/120589.html -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11713> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #10303: Make it easier to print stack traces when debugging GHC itself
by GHC 17 Mar '16

17 Mar '16

#10303: Make it easier to print stack traces when debugging GHC itself -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- As suggested in [http://mail.haskell.org/pipermail/ghc- devs/2015-February/008271.html the mailing list], GHC should have better support for printing its own stack trace when profiling is enabled. This ticket is to track progress toward this goal. There are a few moving parts: * Just having `pprTrace` use `traceStack` is a bad idea, because a profiled compiler will spew lots and lots and lots of output. Instead, I propose a new `pprTraceStack :: String -> SDoc -> a -> a`. * Currently, `ASSERT` will print a stack trace, but it's sometimes the wrong one. `ASSERT` throws an error; if this error is caught and re- thrown, the stack trace is at the re-throw. Instead, it should be at the origin. * Is it worth adding a new mode in `build.mk` that enables profiling, `DEBUG`, and `-fprof-auto`, just to get good stack traces? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10303> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #9803: Poor error message for unbound variable in pattern synonym
by GHC 17 Mar '16

17 Mar '16

#9803: Poor error message for unbound variable in pattern synonym -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 | Type of failure: hour) | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- When I say {{{ pattern OneElt = [x] }}} I get {{{ Right-hand side of bidirectional pattern synonym cannot be used as an expression [x] }}} I have two complaints with this error message: 1. It's very unclear what's actually wrong with the pattern -- `[x]` looks like a perfectly fine expression, until I realize that `x` is unbound. 2. The herald of the error is more than 80 characters (if you count the indentation) and wraps on my 80-character terminal. GHC tends to avoid this elsewhere, and so the wrapping is suboptimal. I would easily say that issue (1) is more important than issue (2). Perhaps this would be better: {{{ Variable `x' is unbound in the bidirectional pattern synonym `OneElt': [x] }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9803> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #8132: Warning for Typeable instances misplaced
by GHC 17 Mar '16

17 Mar '16

#8132: Warning for Typeable instances misplaced -------------------------+------------------------------------------------- Reporter: | Owner: scottgw | Status: new Type: bug | Milestone: Priority: | Version: 7.7 normal | Operating System: Unknown/Multiple Component: | Type of failure: Incorrect warning at Compiler | compile-time Keywords: | Test Case: Architecture: | Blocking: Unknown/Multiple | Difficulty: | Unknown | Blocked By: | Related Tickets: | -------------------------+------------------------------------------------- There is currently a warning for hand-rolled instances of Typeable. However, this leads to some pretty surprising error messages: because the instance is ignored any code that relies on that instance in the same module just fails, which appears pretty weird to the user. {{{ #!haskell import Data.Typeable data K = K instance Typeable K where typeRep _ = undefined ex :: TypeRep ex = typeRep (undefined :: Proxy K) }}} Gives as an error: {{{ No instance for (Typeable * K) arising from a use of ‛typeRep’ In the expression: typeRep (undefined :: Proxy K) In an equation for ‛ex’: ex = typeRep (undefined :: Proxy K) }}} Which is of course surprising because the user just defined the instance. After commenting out the code that uses the instance, one gets: {{{ TypEx.hs:1:1: Warning: Typeable instances can only be derived; ignoring the following instance: instance Typeable * K -- Defined at TypEx.hs:5:10 }}} This information should clearly be somehow presented before or with the previous error if the user is to have any way to figure out what is going on. I suppose this could be fixed by: 1. Turning the Typeable instance warning into an error 2. Checking the missing instance in the existing error for Typeable and suggest that the user should look for hand written instances as a source of the problem. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8132> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

[GHC] #11642: Typechecker doesn't use evidence available from pattern synonym?
by GHC 16 Mar '16

16 Mar '16

#11642: Typechecker doesn't use evidence available from pattern synonym? -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Either that or I am missing something... Consider the following, {{{#!hs {-# LANGUAGE GADTs, PolyKinds, PatternSynonyms, RankNTypes, TypeOperators, ViewPatterns #-} module Test where data TypeRep (a :: k) where TypeCon :: String -> TypeRep a TypeApp :: TypeRep f -> TypeRep x -> TypeRep (f x) data TypeRepX where TypeRepX :: TypeRep a -> TypeRepX data (a :: k1) :~~: (b :: k2) where HRefl :: a :~~: a trArrow :: TypeRep (->) trArrow = undefined eqTypeRep :: TypeRep (a :: k1) -> TypeRep (b :: k2) -> Maybe (a :~~: b) eqTypeRep = undefined typeRepKind :: forall (k :: *). forall (a :: k). TypeRep a -> TypeRep k typeRepKind = undefined pattern TRFun :: forall fun. () => forall arg res. (fun ~ (arg -> res)) => TypeRep arg -> TypeRep res -> TypeRep fun pattern TRFun arg res <- TypeApp (TypeApp (eqTypeRep trArrow -> Just HRefl) arg) res buildApp :: TypeRepX -> TypeRepX -> TypeRepX buildApp (TypeRepX f) (TypeRepX x) = case typeRepKind f of TRFun arg _ -> case eqTypeRep arg x of Just HRefl -> TypeRepX $ TypeApp f x }}} This fails with, {{{ $ ghc Test.hs -fprint-explicit-kinds [1 of 1] Compiling Test ( Test.hs, Test.o ) Test.hs:38:30: error: • Expected kind ‘TypeRep (k1 -> res) a’, but ‘f’ has kind ‘TypeRep k a’ • In the first argument of ‘TypeApp’, namely ‘f’ In the second argument of ‘($)’, namely ‘TypeApp f x’ In the expression: TypeRepX $ TypeApp f x • Relevant bindings include arg :: TypeRep * arg (bound at Test.hs:35:11) }}} That is, the typechecker doesn't believe that `f`'s type (why is it saying "kind" here?), `TypeRep k a`, will unify with `TypeRep (k1 -> res) a`, despite the `TRFun` pattern match, which should have brought into scope that `k ~ (arg -> res)`. This was tested with a recent snapshot from `ghc-8.0` (23baff798aca5856650508ad0f7727045efe3680). Am I missing something here or is this a bug? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11642> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11