November 2014 - ghc-tickets

[GHC] #9405: Ticky results should be displayed even during interrupts (Ctrl-c)
by GHC 24 Mar '16

24 Mar '16

#9405: Ticky results should be displayed even during interrupts (Ctrl-c) -------------------------------------+------------------------------------- Reporter: thoughtpolice | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- After talking with Simon & Simon today, we discussed ticky profiling, and it dawned on us that ticky probably isn't reported when the program is interrupted via the user. But it should be! The motivating case is when you're dealing with an infinite loop and you want to find the binding that has a high entry count (i.e. it's the looping body). But the only way to move forward is to interrupt it, which doesn't spit out the reports. Fixing this would make ticky much more useful in such cases. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9405> 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] #9699: TH function to list names in scope
by GHC 07 Mar '16

07 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] #9043: Add missing type class instances for data types in GHC.Generics
by GHC 27 Feb '16

27 Feb '16

#9043: Add missing type class instances for data types in GHC.Generics ------------------------------------+------------------------------------- Reporter: ocharles | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/base | 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: | ------------------------------------+------------------------------------- GHC.Generics offers a bunch of data types which have valid instances of various type classes in base, such as Functor. There's no good reason not to have these instances, so they should be added. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9043> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 38

[GHC] #8710: Overlapping patterns warning misplaced
by GHC 27 Feb '16

27 Feb '16

#8710: Overlapping patterns warning misplaced -------------------------+------------------------------------------------- Reporter: | Owner: goldfire | Status: new Type: bug | Milestone: Priority: low | Version: 7.7 Component: | Operating System: Unknown/Multiple Compiler | Type of failure: Incorrect warning at Keywords: | compile-time Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: | Unknown | Blocked By: | Related Tickets: | -------------------------+------------------------------------------------- Consider {{{ {-# OPTIONS_GHC -fwarn-overlapping-patterns #-} len [] = 0 len (_:t) = 1 + len t len _ = error "urk" }}} GHC reports the problem with this definition at the first line of it. I think it would be more helpful to have it at the last line, which is the pattern that will never match. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8710> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 22

[GHC] #8176: Language extensions not registered
by GHC 20 Feb '16

20 Feb '16

#8176: Language extensions not registered --------------------------------+------------------------------------------ Reporter: duncan | Owner: thoughtpolice Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: tests/driver/T4437.hs Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | --------------------------------+------------------------------------------ tests/driver/T4437.hs does not seem to be being used properly. That test is there to make sure that ghc developers do not forget to register their new extensions with Cabal. But it looks like it's just being silenced and they are being forgotten again. Recall, the protocol is that all Haskell implementations can register their extensions in the central location (which is Language.Haskell.Extensions in the Cabal package) when they are happy that they are ready for public consumption. This matters to users because extensions that are not ready for public consumption (ie not registered) cannot be used in packages uploaded to hackage. Currently `tests/driver/T4437.hs` contains: {{{ expectedGhcOnlyExtensions = [ "AllowAmbiguousTypes", "RelaxedLayout", "AlternativeLayoutRule", "AlternativeLayoutRuleTransitional", "ExplicitNamespaces", "TypeHoles", "OverloadedLists", "EmptyCase", "AutoDeriveTypeable", "NegativeLiterals", "NullaryTypeClasses"] }}} This looks like a much bigger list than it should be. Surely not all of these extensions are private to ghc or are still under development and not to be used? But if they are listed here, then the test doesn't complain about them. And the whole point of this test is to stop ghc devs from forgetting to register them. I think we need to change the test so that we distinguish between extensions that are really not ready, and ones that are on-track to be public. It should be a release blocker for the "on-track to be public" ones to still not be registered. The test should have comments giving this guidance for ghc contributors. I'm not quite sure how we adjust the test to make that happen (ie different behaviour for RC-build vs normal hacking validate). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8176> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

[GHC] #9518: Improve error message for unacceptable role annotations
by GHC 19 Feb '16

19 Feb '16

#9518: Improve error message for unacceptable role annotations -------------------------------------+------------------------------------- Reporter: dmcclean | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler | 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: -------------------------------------+------------------------------------- It would be nice if this message: {{{ Role mismatch on variable a: Annotation says representational but role nominal is required while checking a role annotation for `Point' }}} Could be extended to say where the requirement arises. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9518> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #8981: ghc-pkg complains about missing haddock interface files
by GHC 19 Feb '16

19 Feb '16

#8981: ghc-pkg complains about missing haddock interface files --------------------------+------------------------------------------------ Reporter: | Owner: thoughtpolice | Status: new Type: bug | Milestone: 7.8.2 Priority: normal | Version: 7.8.1 Component: | Operating System: MacOS X Compiler | Type of failure: Incorrect result at runtime Keywords: ghc- | Test Case: pkg | Blocking: Architecture: x86_64 | (amd64) | Difficulty: | Unknown | Blocked By: | Related Tickets: | --------------------------+------------------------------------------------ As Conal reported on the mailing list[1], `ghc-pkg check` on Mavericks allegedly returns: {{{ bash-3.2$ ghc-pkg check Warning: haddock-interfaces: /Users/conal/.cabal/share/doc/x86_64-osx- ghc-7.8.1/uniplate-1.6.12/html/uniplate.haddock doesn't exist or isn't a file Warning: haddock-interfaces: /Users/conal/.cabal/share/doc/x86_64-osx- ghc-7.8.1/polyparse-1.9/html/polyparse.haddock doesn't exist or isn't a file Warning: haddock-interfaces: /Users/conal/.cabal/share/doc/x86_64-osx- ghc-7.8.1/ghc-syb-utils-0.2.1.2/html/ghc-syb-utils.haddock doesn't exist or isn't a file Warning: haddock-interfaces: /Users/conal/.cabal/share/doc/x86_64-osx- ghc-7.8.1/constraints-0.3.5/html/constraints.haddock doesn't exist or isn't a file Warning: haddock-html: /Users/conal/.cabal/share/doc/x86_64-osx- ghc-7.8.1/constraints-0.3.5/html doesn't exist or isn't a directory Warning: haddock-interfaces: /Users/conal/.cabal/share/doc/x86_64-osx- ghc-7.8.1/newtype-0.2/html/newtype.haddock doesn't exist or isn't a file Warning: haddock-html: /Users/conal/.cabal/share/doc/x86_64-osx- ghc-7.8.1/newtype-0.2/html doesn't exist or isn't a directory }}} It's not fatal, but makes the output much more annoying. I figured this would have been caught by validate or somesuch, but apparently not. Marking for 7.8.2. I'm looking into this soon. [1]http://www.haskell.org/pipermail/glasgow-haskell- users/2014-April/024846.html -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8981> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #9611: Suggest the cause of "No instance" errors involving multiple versions of a package
by GHC 18 Feb '16

18 Feb '16

#9611: Suggest the cause of "No instance" errors involving multiple versions of a package -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | 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: -------------------------------------+------------------------------------- Suppose I have packages A-1.0, A-1.1, and B-1.0 built against A-1.0, and A (both versions) defines a type T which B defines to be an instance of some class C. If I load A-1.1 and B-1.0 into ghci and try to use the C T instance I will get a "No instance for C T" error, because T refers to A-1.1:T and B only defines an instance for A-1.0:T. However, if I don't realize this is what's going on, the error will be quite confusing as B appears to define an instance C T. Or, A could define the class C, rather than the type T, with the same result. This is quite common nowadays because there is a newer version of transformers (0.4.1.0) than the one which ships with GHC (0.3.0.0) and it's easy to end up installing mtl or lens against 0.3.0.0, and then some other package which pulls in 0.4.1.0. It would be nice to give a hint about what is going on, like {{{ No instance for (MonadIO X) arising from a use of ‘liftIO’ In the expression: ... ... Note: there is an instance transformers-0.3.0.0:MonadIO X }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9611> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8