October 2015 - ghc-tickets

[GHC] #10959: MINIMAL pragma and default implementations
by GHC 12 Oct '15

12 Oct '15

#10959: MINIMAL pragma and default implementations -------------------------------------+------------------------------------- Reporter: basvandijk | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The `ToJSON` class from the `aeson` library recently gained the new method `toEncoding` which has a default implementation based on the existing `toJSON` method. A MINIMAL pragma was added to `toJSON` to make sure instances will define it. However, `toJSON` also has a default implementation but only if the type has an instance for `Generic`: {{{ class ToJSON a where toJSON :: a -> Value {-# MINIMAL toJSON #-} default toJSON :: (Generic a, GToJSON (Rep a)) => a -> Value toJSON = genericToJSON defaultOptions toEncoding :: a -> Encoding toEncoding = Encoding . E.encodeToBuilder . toJSON }}} The problem is that users of `aeson` who are using the generic implementation get warnings that their `toJSON` method is not defined: {{{ No explicit implementation for ‘toJSON’ In the instance declaration for ‘ToJSON MyType’ }}} It would be nice if GHC is a bit smarter in this case so that when a a default implementation is used it won't give the warning. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10959> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #10611: Runtime crash while running psc
by GHC 12 Oct '15

12 Oct '15

#10611: Runtime crash while running psc -------------------------------------+------------------------------------- Reporter: qxjit | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Runtime crash (amd64) | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Got a runtime crash while running the purescript compiler: psc: internal error: evacuate(static): strange closure type 6647784 (GHC version 7.8.3 for x86_64_unknown_linux) As yet I have not be able to reproduce it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10611> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #10733: Improving the error message for type variable ambiguity
by GHC 12 Oct '15

12 Oct '15

#10733: Improving the error message for type variable ambiguity -------------------------------------+------------------------------------- Reporter: Rufflewind | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- This is a summary of a [https://mail.haskell.org/pipermail/ghc- devs/2015-August/009522.html discussion on ghc-devs]. The current message when a type variable is ambiguous could use a little rewording to improve its friendliness towards the user. Currently, it looks like this: {{{ No instance for (Foldable t0) arising from a use of ‘elem’ The type variable ‘t0’ is ambiguous Relevant bindings include valid :: t0 Char (bound at …) Note: there are several potential instances: instance Foldable (Either a) -- Defined in ‘Data.Foldable’ instance Foldable Data.Proxy.Proxy -- Defined in ‘Data.Foldable’ instance GHC.Arr.Ix i => Foldable (GHC.Arr.Array i) -- Defined in ‘Data.Foldable’ ...plus three others }}} The focus seems to be on "No instance", which, while technically correct, does not usually lead to the correct solution of the problem. In particular, the "type variable is ambiguous" does not appear until the 2nd or 3rd line, making it easy to miss, which may lead to confusion with other kinds of "No instance" errors that have a similar leading sentence. There are two ways to fix this error usually: * By defining `instance Foldable t0`, but this is rarely what the user wants. * By fixing the ambiguity using a type annotation. Given that the latter seems to be a more likely cause, it may help if the error message were rewritten to prioritize that, while also leaving the first solution open if the user really knows what they are doing. Therefore, it is suggested that the message should reword in a way similar to this: {{{ Ambiguous type variable ‘t0’ arising from a use of ‘elem’ caused by the lack of an instance ‘(Foldable t0)’ Relevant bindings include valid :: t0 Char (bound at …) Either use a type annotation to specify what ‘t0’ should be based on these potential instance(s): instance Foldable (Either a) -- Defined in ‘Data.Foldable’ instance Foldable Data.Proxy.Proxy -- Defined in ‘Data.Foldable’ instance GHC.Arr.Ix i => Foldable (GHC.Arr.Array i) ... plus three others and possibly more from other modules that the compiler has not yet encountered or define the required instance ‘(Foldable t0)’ }}} which puts the emphasis on "ambiguous type variable" in the first few words while also outlining the possible solutions for the user and reminding them of the open-world assumption. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10733> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

Re: [GHC] #1853: hpc mix files for Main modules overwrite each other
by GHC 12 Oct '15

12 Oct '15

#1853: hpc mix files for Main modules overwrite each other ----------------------------------+-------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: lowest | Milestone: 8.0.1 Component: Code Coverage | Version: 6.8.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+-------------------------------------- Changes (by thomie): * cc: andygill@… (added) Comment: @AndyGill: any comments on the proposal from comment:18? @mgsloan: I'm still curious what Andy (the creator of hpc) had in mind in comment:12, but if your proposal solves the problem, and you don't hear from Andy, please go ahead. Sorry for not giving real feedback. I don't really know much about hpc at all, and I don't think anyone else does either (*cough* technical debt *cough*), but I trust you to do the right thing and will make sure your patches get reviewed/merged. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1853#comment:20> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10956: Allow default keyboard behavior to be easily overriden
by GHC 11 Oct '15

11 Oct '15

#10956: Allow default keyboard behavior to be easily overriden -------------------------------------+------------------------------------- Reporter: | Owner: BalinKingOfMoria | Type: feature | Status: new request | Priority: normal | Milestone: Component: Runtime | Version: 7.8.3 System | Keywords: io input raw | Operating System: Windows Architecture: x86_64 | Type of failure: Incorrect result (amd64) | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- If I press the up or down arrow keys, GHC kicks in and makes it so that the last line of text comes back instead of letting me intercept the arrow key. From what I have seen, you need third-party libraries to override the default behavior, but when would a user actually want that behavior in an application instead of letting the programmer handle it? Can there be a switch (like a special LANGUAGE pragma or whatever) to enable raw input capture? Console text editing applications are greatly hindered by this automatic behavior. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10956> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

Re: [GHC] #5642: Deriving Generic of a big type takes a long time and lots of space
by GHC 11 Oct '15

11 Oct '15

#5642: Deriving Generic of a big type takes a long time and lots of space -------------------------------------+------------------------------------- Reporter: basvandijk | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: T5642 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): For the record this sounds quite similar to #8095 in that the compiler seems to be creating long strings of coercions (although here the simplifier doesn't even seem capable of eliminating them). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5642#comment:24> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5642: Deriving Generic of a big type takes a long time and lots of space
by GHC 11 Oct '15

11 Oct '15

#5642: Deriving Generic of a big type takes a long time and lots of space -------------------------------------+------------------------------------- Reporter: basvandijk | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: T5642 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * owner: dimitris => bgamari Comment: I'll be looking into this. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5642#comment:23> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10913: deprecate and then remove -fwarn-hi-shadowing
by GHC 10 Oct '15

10 Oct '15

#10913: deprecate and then remove -fwarn-hi-shadowing -------------------------------------+------------------------------------- Reporter: osa1 | Owner: Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 7.10.2 Keywords: newcomer | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- I realized that the flag is not used in the compiler at all, and @slyfox realized that the flag was last used in 2006. He also found out that there are 355 packages in the Hackage that use this useless flag. So we should maybe first deprecate it and remove it later. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10913> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

Re: [GHC] #1883: GHC can't find library using "short" name
by GHC 10 Oct '15

10 Oct '15

#1883: GHC can't find library using "short" name -------------------------------------+------------------------------------- Reporter: m4dc4p | Owner: Phyx- Type: bug | Status: closed Priority: lowest | Milestone: 8.0.1 Component: Compiler | Version: 6.6.1 Resolution: fixed | Keywords: link library | windows Operating System: Windows | Architecture: x86 Type of failure: None/Unknown | Test Case: Blocked By: 3658 | Blocking: Related Tickets: #2283 #3242 | Differential Rev(s): Phab:D1310 #1883 #7097 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by m4dc4p): So awesome to see this fixed! nice work. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1883#comment:29> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2189: hSetBuffering stdin NoBuffering doesn't work on Windows
by GHC 10 Oct '15

10 Oct '15

#2189: hSetBuffering stdin NoBuffering doesn't work on Windows -------------------------------------+------------------------------------- Reporter: FalconNL | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Core Libraries | Version: 6.8.2 Resolution: | Keywords: hsetbuffering | buffering buffer Operating System: Windows | Architecture: x86 Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by BalinKingOfMoria): Replying to [comment:48 rwbarton]: > Definitely not going to happen for 7.10.3. In the meantime, are there any viable workarounds (that haven't since been rolled back)? Raw input would be very helpful on Windows. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2189#comment:49> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0