March 2015 - ghc-tickets

[GHC] #9995: :info enhancements
by GHC 05 Mar '15

05 Mar '15

#9995: :info enhancements -------------------------------------+------------------------------------- Reporter: shachaf | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.4 Component: GHCi | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- `:info` is a very useful ghci command, but there are several improvements that could be made: * It would be useful if `:i` showed not only which module a name is defined in, but which module(s) it was imported from in the current session. * A variant of `:i` that just prints a definition, rather than a definition and all instances, would be useful in many cases. E.g. `:i Show` prints the definition of `Show`, but then it prints so many instances that the definition is scrolled way off the screen. * `:i ->` is a parse error; it should behave like `:i (->)`, the way it works for other type-level operators. * hvr had some more suggestions: "finding out which package a module belongs to", "and what module an 'as'-alias is associated with". (Currently I think modules are out of `:info`'s scope, but perhaps it would be a useful addition.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9995> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #9987: GHC refuses to compile a file that starts with a Byte Order Mark (BOM)
by GHC 05 Mar '15

05 Mar '15

#9987: GHC refuses to compile a file that starts with a Byte Order Mark (BOM) -------------------------------------+------------------------------------- Reporter: Henk-Jan | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.10.1-rc1 Keywords: | Operating System: Windows Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Trying to compile a file that starts with a Byte Order Mark (BOM) results in the message like: Camels.hs:1:1: lexical error at character '\65279' No compilation is done. Note that, if a file is saved as UTF-8, Notepad adds this BOM to the beginning of the file. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9987> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #10132: Inconsistent kind polymorphism for top-level and associated type families
by GHC 05 Mar '15

05 Mar '15

#10132: Inconsistent kind polymorphism for top-level and associated type families -------------------------------------+------------------------------------- Reporter: simonpj | 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: | -------------------------------------+------------------------------------- Consider this, with `-XPolyKinds`: {{{ class C a where data D1 a type F1 a data D2 a type F2 a }}} You'd expect `D1` and `D2` to behave exactly the same; and similarly `F1` and `F2`. But they don't: {{{ D1 :: forall k (a:k). k -> * D2 :: * -> * F1 :: forall k (a:k). k -> * F2 :: * -> * }}} This seems odd. Indeed, when I stumbled across it I thought it was a plain bug. But I think there is some justification: * For associated types like `D1`, `F1` we make the class kind-polymorphic by default. And hence the associated types really have to be also. * Should classes be by-default kind-polymorphic? Well, data types are, so probably classes should be too. The types of the methods of the class, or the constructors of the data type, usually give plenty of clues. * For top-level types like `D2`, `F2`, it seems perhaps overkill to make them kind polymorphic by default. The difference is that they have no right hand side to get clues from, so they'll always have kind `k1 -> k2 -> k3` if you go for maximal polymorphism. You can declare the polymorphism with kind signatures. * Why does `F1` return `*`. It could as well be kind-polymorphic in its result. Again I think this is because there cannot be any clue as to its result kind so we default to `*`. Maybe this is all a good choice. The principle seems to be: '''if the declaration has a "right hand side", infer kinds from that; if not, default to `*`'''. But even if that is the right principle, we should articulate it explicitly, in the user manual and a `Note` somewhere. (I reverse-engineered all this when looking at #9999 again, in the new `Typeable` branch.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10132> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

Re: [GHC] #3321: -fhpc assumes original sources relative to the current directory
by GHC 05 Mar '15

05 Mar '15

#3321: -fhpc assumes original sources relative to the current directory -------------------------------------+------------------------------------- Reporter: duncan | Owner: Type: bug | Status: closed Priority: lowest | Milestone: 7.12.1 Component: Code Coverage | Version: 6.10.1 Resolution: worksforme | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * cc: ttuegel (added) * status: new => closed * resolution: => worksforme Comment: @duncan, @ttuegel: I think this works now (the issue was opened 7 years ago). Please reopen if you find ghc still doesn't handle the combination of `-fhpc` and `-i` properly. {{{ $ mkdir a $ mkdir b $ cat > ./a/A.hs <<EOF module A where import B EOF $ cat > ./B.hsc <<EOF module B where EOF $ hsc2hs B.hsc -o b/B.hs $ cd a $ ghc-7.8.4 --make A.hs -i../b -fhpc [1 of 2] Compiling B ( ../b/B.hs, ../b/B.o ) [2 of 2] Compiling A ( A.hs, A.o ) }}} Note that we don't get an error message that the source for `B` can not be found, with or without `-fhpc`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3321#comment:13> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

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

04 Mar '15

#1853: hpc mix files for Main modules overwrite each other -------------------------------------+------------------------------------- Reporter: guest | Owner: AndyGill Type: bug | Status: new Priority: lowest | Milestone: 7.12.1 Component: Code Coverage | Version: 6.8.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: None/Unknown | (amd64) Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by thomie): Replying to [comment:12 andygill]: > This one is tricky to fix, because of a baked in assumption. If anyone wants to help, or if I can find a willing student, I can give guidance about how to fix it. @andygill. I am currently looking at hpc. Do you think this issue is worth fixing? Multiple programs in the same directory can be nicely handled using `-main-is`. The following doesn't overwrite any .mix files: {{{#!hs $ cat ProgramA.hs module ProgramA where main = return () $ cat ProgramB.hs module ProgramB where main = return () $ ghc -fhpc -main-is ProgramA ProgramA $ ghc -fhpc -main-is ProgramB ProgramB $ ls .hpc ProgramA.mix ProgramB.mix }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1853#comment:16> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2224: -fhpc inteferes/prevents rewrite rules from firing
by GHC 04 Mar '15

04 Mar '15

#2224: -fhpc inteferes/prevents rewrite rules from firing -------------------------------------+------------------------------------- Reporter: dons | Owner: andy@… Type: bug | Status: new Priority: lowest | Milestone: 7.12.1 Component: Code Coverage | Version: 6.8.2 Resolution: | Keywords: rules, hpc Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Description changed by thomie: Old description: > Use case: > > I'm writing tests for rewrite rules, and using HPC to determine if rules > were fired (and their code exercised). HPC is quite cool here, since it > lets us see which rules fired, without needing to explicitly export > functions to test. > > However, -fhpc seems to prevent many rules from firing (likely due to > ticks getting in the way?) > > For example: > > {{{ > import qualified Data.ByteString.Char8 as C > > main = print (C.pack "literal") > }}} > > When compiled normally, triggers a nice rewrite rule: > > {{{ > $ ghc -O2 A.hs -ddump-rule-firings A.hs -c > Rule fired: unpack > Rule fired: Class op show > Rule fired: unpack-list > Rule fired: ByteString packChars/packAddress > Rule fired: unpack > Rule fired: Class op show > Rule fired: unpack-list > Rule fired: ByteString packChars/packAddres > }}} > > Now with -fhpc: > > {{{ > $ ghc -O2 A.hs -ddump-rule-firings A.hs -c -fhpc > Rule fired: unpack > Rule fired: Class op show > Rule fired: unpack-list > Rule fired: unpack > Rule fired: Class op show > Rule fired: unpack-list > }}} > > What's the best way to ensure the same code is exercised with and without > -fhpc here? (I'd quite like to get this working, since rewrite rules > benefit from testing.) New description: Use case: I'm writing tests for rewrite rules, and using HPC to determine if rules were fired (and their code exercised). HPC is quite cool here, since it lets us see which rules fired, without needing to explicitly export functions to test. However, -fhpc seems to prevent many rules from firing (likely due to ticks getting in the way?) For example: {{{ import qualified Data.ByteString.Char8 as C main = print (C.pack "literal") }}} When compiled normally, triggers a nice rewrite rule: {{{ $ ghc -O2 A.hs -ddump-rule-firings -c Rule fired: unpack Rule fired: Class op show Rule fired: unpack-list Rule fired: ByteString packChars/packAddress }}} Now with -fhpc: {{{ $ ghc -O2 A.hs -ddump-rule-firings A.hs -c -fhpc Rule fired: unpack Rule fired: Class op show Rule fired: unpack-list }}} What's the best way to ensure the same code is exercised with and without -fhpc here? (I'd quite like to get this working, since rewrite rules benefit from testing.) -- -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2224#comment:19> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10118: No ambiguity check when `ConstrainedClassMethods` is on
by GHC 04 Mar '15

04 Mar '15

#10118: No ambiguity check when `ConstrainedClassMethods` is on -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.10.1-rc2 (Type checker) | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: #7854 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The following program is wrongfully accepted when `ConstrainedClassMethods` is on: {{{#!hs module ShouldFail where class Foo a where op :: Eq b => a -> Int }}} I have a fix. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10118> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #10119: Class methods must always mention the class variable
by GHC 04 Mar '15

04 Mar '15

#10119: Class methods must always mention the class variable -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.10.1-rc2 (Type checker) | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: #7854, #10118 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- As mentioned in comment:9:ticket:7854, GHC wrongfully accepts the following program. It should reject it, because `op` doesn't mention any type variables of `Foo` (the method context doesn't count). {{{#!hs module ShouldFail where class Foo a where op :: Eq a => Int }}} I'm working on it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10119> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

Re: [GHC] #7854: Constrained method type accepted in Haskell 98 mode
by GHC 04 Mar '15

04 Mar '15

#7854: Constrained method type accepted in Haskell 98 mode -------------------------------------+------------------------------------- Reporter: refold | Owner: thomie Type: bug | Status: closed Priority: normal | Milestone: 7.12.1 Component: Compiler (Type | Version: 7.6.3 checker) | Keywords: newcomer Resolution: fixed | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | module/mod39 Related Tickets: #10118, #10119 | Blocking: | Differential Revisions: Phab:D688 -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones <simonpj@…>): In [changeset:"3aa2519ec29156f57a862a033bc7a902b742a2e0/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="3aa2519ec29156f57a862a033bc7a902b742a2e0" Check for equality before deferring This one was a bit of a surprise. In fixing Trac #7854, I moved the checkAmbiguity tests to checkValidType. That meant it happened even for monotypes, and that turned out to be very expensive in T9872a, for reasons described in this (new) Note in TcUnify: Note [Check for equality before deferring] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Particularly in ambiguity checks we can get equalities like (ty ~ ty). If ty involves a type function we may defer, which isn't very sensible. An egregious example of this was in test T9872a, which has a type signature Proxy :: Proxy (Solutions Cubes) Doing the ambiguity check on this signature generates the equality Solutions Cubes ~ Solutions Cubes and currently the constraint solver normalises both sides at vast cost. This little short-cut in 'defer' helps quite a bit. I fixed the problem with a quick equality test, but it feels like an ad- hoc solution; I think we might want to do something in the constraint solver too. (The problem was there all along, just more hidden.) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7854#comment:14> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7854: Constrained method type accepted in Haskell 98 mode
by GHC 04 Mar '15

04 Mar '15

#7854: Constrained method type accepted in Haskell 98 mode -------------------------------------+------------------------------------- Reporter: refold | Owner: thomie Type: bug | Status: closed Priority: normal | Milestone: 7.12.1 Component: Compiler (Type | Version: 7.6.3 checker) | Keywords: newcomer Resolution: fixed | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | module/mod39 Related Tickets: #10118, #10119 | Blocking: | Differential Revisions: Phab:D688 -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones <simonpj@…>): In [changeset:"9dc0d63cd7231392320e4afcfe78102801126d34/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="9dc0d63cd7231392320e4afcfe78102801126d34" Three other test updates following the fix to Trac #7854 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7854#comment:15> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0