December 2015 - ghc-tickets

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

17 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] #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 16 Mar '16

16 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] #9887: No message when GCHI reusing compiled code
by GHC 12 Mar '16

12 Mar '16

#9887: No message when GCHI reusing compiled code -------------------------------------+------------------------------------- Reporter: jsrice | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 | Type of failure: Other hour) | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Running ":l Main.hs" at the GHCI prompt would load the compiled module. I am new to Haskell and this was a stumbling block that made it so that I could not interactively debug my code with GHCI. Deleting the object files was suggested to me on IRC and that allowed me to get the "*Main" prompt I was looking for. A message warning users "reusing compiled code" would likely save some future users some time. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9887> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #10691: certain operations in new integer-gmp are too lazy
by GHC 11 Mar '16

11 Mar '16

#10691: certain operations in new integer-gmp are too lazy -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries | Version: 7.10.1 (other) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- This came up in #ghc the other day. {{{ rwbarton@morphism:~$ ghci-7.10.1 GHCi, version 7.10.1: http://www.haskell.org/ghc/ :? for help Prelude> undefined * 0 0 }}} For consistency not just with Int, but also other integer-* implementations, this should be undefined. Also affected is for example `andInteger`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10691> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #9699: TH function to list names in scope
by GHC 06 Mar '16

06 Mar '16

#9699: TH function to list names in scope -------------------------------------+------------------------------------- Reporter: MikeIzbicki | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- I [asked about this on stackoverflow](http://stackoverflow.com/questions/26394199/using- templatehaskell-to-list-all-names-in-a-namespace), and apparently it doesn't exist yet. I want a TemplateHaskell function `variablesInScope :: Q [Name]` that returns a list of the `Name`'s of all the variables in scope. TemplateHaskell obviously has this information available in order to implement functions like `reify :: Name -> Q Info` and `lookupValueName :: String -> Q (Maybe Name)`. So it seems like this might be a pretty simple function to add. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9699> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #10472: SigOf tests fail following renamer tidy-up
by GHC 01 Mar '16

01 Mar '16

#10472: SigOf tests fail following renamer tidy-up -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | 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: | -------------------------------------+------------------------------------- I'm about to commit a patch that fixes #7672. Sadly, though, it causes these failures {{{ driver/sigof02 sigof02dmt [bad stderr] (normal) driver/sigof02 sigof02dt [bad stderr] (normal) driver/sigof02 sigof02mt [bad exit code] (normal) driver/sigof02 sigof02t [bad exit code] (normal) }}} with errors like {{{ Main.hs:8:13: error: Can't find interface-file declaration for variable empty Probable cause: bug in .hi-boot file, or inconsistent .hi file Use -ddump-if-trace to get an idea of which file caused the error In the second argument of ‘($)’, namely ‘empty’ In the expression: insert 0 "foo" . delete 1 . insert 1 undefined . insert (6 :: Int) "foo" $ empty In an equation for ‘x’: x = insert 0 "foo" . delete 1 . insert 1 undefined . insert (6 :: Int) "foo" $ empty Main.hs:10:12: error: Can't find interface-file declaration for variable toList Probable cause: bug in .hi-boot file, or inconsistent .hi file Use -ddump-if-trace to get an idea of which file caused the error In the first argument of ‘print’, namely ‘(toList x)’ In a stmt of a 'do' block: print (toList x) In the expression: do { let x = insert 0 "foo" . delete 1 . insert 1 undefined . insert (6 :: Int) "foo" $ empty; print (member 1 x); print (toList x); print x } }}} Clearly there is only one bug here, and it's in the signature-handling code, which I do not fully understand. Happily, it's Edward's territory, and he is also involved in #7672. So I plan to mark these tests as broken on this ticket, and hope that Edward can adapt the signature stuff (which in any case is in-flight) to the new code. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10472> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #10873: Bad error message for incorrect pattern synonym signature
by GHC 29 Feb '16

29 Feb '16

#10873: Bad error message for incorrect pattern synonym signature -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 (Type checker) | Keywords: newcomer | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Consider the following program {{{ {-# LANGUAGE PatternSynonyms #-} pattern Pat :: Show a => () => a -> Maybe a pattern Pat a = Just a }}} GHC complains that {{{ test.hs:4:9: No instance for (Show a) arising from a pattern }}} I think this is quite difficult to understand. The problem is that matching on `Just a` doesn't provide the show constraint (it provides no constraints). A better error message here would explain this fact and maybe a short explanation of the difference between prov/req in a pattern synonym signature. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10873> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #11134: Limit frequency of idle GCs
by GHC 29 Feb '16

29 Feb '16

#11134: Limit frequency of idle GCs -------------------------------------+------------------------------------- Reporter: dcturner | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Runtime | Version: 7.10.2 System | 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: -------------------------------------+------------------------------------- In a server process with a relatively large heap (100s of MB) serving regular but relatively infrequent requests (~1 per sec) the idle GC runs after essentially every request which turns out to be extremely expensive: switching it off takes us from ~30% CPU to ~0.3% CPU. It is certainly useful have the GC run when idle but running it *every* time the process goes idle isn't necessary. It doesn't work to increase the delay (e.g. say -I2) as then the idle GC would never run, because the requests are rather regular. I'd quite like to be able to say something of the form "do a GC if idle for at least 0.3s as long as the idle GC has not run in the last 120s" - where 120s is another option passed to the RTS. Does this sound like a reasonable idea? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11134> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3