March 2016 - ghc-tickets

[GHC] #11674: GHC accepts overly general instance sigs
by GHC 05 Mar '16

05 Mar '16

#11674: GHC accepts overly general instance sigs -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: InstanceSigs | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC accepts Unknown/Multiple | invalid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs {-# LANGUAGE InstanceSigs #-} data I a = MkI a instance Functor I where fmap :: (a -> b) -> f a -> f b fmap = undefined }}} is accepted when the type is too general, even things like: {{{#!hs fmap :: (a -> b) -> f a -> g b -- & fmap :: whoami }}} are accepted -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11674> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #11666: Severe performance degradation in GHC 8.0.1 compared to GHC 7.10.x
by GHC 04 Mar '16

04 Mar '16

#11666: Severe performance degradation in GHC 8.0.1 compared to GHC 7.10.x -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc2 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: -------------------------------------+------------------------------------- While working on a project, I have noticed that GHC 8 takes too long to run my test suite on CI server, see for example here: https://travis-ci.org/mrkkrp/zip/builds/113059190 GHC 8 finished in 370 [seconds](https://travis-ci.org/mrkkrp/zip/jobs/113059197#L599), while GHC 7.10.3 in [82 seconds](https://travis-ci.org/mrkkrp/zip/jobs/113059195#L608), 7.10.2 and 7.10.3 demonstrated similar results (77 seconds). There are minor differences in versions of libraries used, mainly those that are shipped with GHC, I read their changelogs and it seems like it's not likely that this sort of slow-down (× 4.5) happened because of one of those libraries. Note that due to the nature of the project I test it does fair amount of IO in temporary directories, I'll be happy to provide more information if you like. BTW, here is the test suite: https://github.com/mrkkrp/zip/blob/master/tests/Main.hs -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11666> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

Re: [GHC] #5296: Add explicit type applications
by GHC 03 Mar '16

03 Mar '16

#5296: Add explicit type applications -------------------------------------+------------------------------------- Reporter: dsf | Owner: goldfire Type: feature request | Status: closed Priority: low | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.0.3 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | typecheck/should_compile/Vta{1,2} | typecheck/should_fail/VtaFail Blocked By: 1897 | Blocking: 10770 Related Tickets: #4466 | Differential Rev(s): Phab:D1681 Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): It depends on what ambiguity means. In a language with visible type application, {{{ foo :: (Show a, Read a) => String -> String }}} can be called quite easily. Thus the ambiguity check seems unhelpful here. Thus the decision to have `TypeApplications` turn on `AllowAmbiguousTypes`. I do see what you're getting at. Perhaps this is the wrong design, and I'm happy to think about changing it (although it does seem a bit late). I will say that if you do want the ambiguity check, you can always use `NoAllowAmbiguousTypes`. If you wish to pursue the issue, I think a good next step is posting to ghc-devs to see what others think. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5296#comment:30> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5296: Add explicit type applications
by GHC 03 Mar '16

03 Mar '16

#5296: Add explicit type applications -------------------------------------+------------------------------------- Reporter: dsf | Owner: goldfire Type: feature request | Status: closed Priority: low | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.0.3 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | typecheck/should_compile/Vta{1,2} | typecheck/should_fail/VtaFail Blocked By: 1897 | Blocking: 10770 Related Tickets: #4466 | Differential Rev(s): Phab:D1681 Wiki Page: | -------------------------------------+------------------------------------- Comment (by andrewthad): This might be a little too late, but I wanted to raise an about the relationship this has with AllowAmbiguousTypes. I haven't tried it out yet, but based on an earlier comment in this thread, I think that turning on VisibleTypeApplication will also turn on AllowAmbiguousTypes. I don't think that this is necessary, and I think that there are situation where it is detrimental the library users. Let's say that I have a `Rec` from `vinyl` and I'm using `rget` from `Data.Vinyl.Lens`. Today, if I have `myRec :: Rec Identity '[Char,Bool,Int]`, I can write `rget (Proxy :: Proxy Int) myRec` to get the `Int` value out. In the future, it may be desirable to write a function `rget2` that can take the argument by VisibleTypeApplication instead. So, we would call `rget2 @Int myRec` instead. Here's the issue that I'm getting at. What does an end user have to enable to be able to use `rget2`? At the definition site, in the case of `rget2`, we actually don't need AllowAmbiguousTypes, but let's pretend that we did (I should have picked a different example). When a user turns on VisibleTypeApplication to be able to use a function that will otherwise have ambiguous type variable instantiation, I don't think that they should get AllowAmbiguousTypes turned on as well. If I understand correctly, AllowAmbiguousTypes is only needed to define these functions, not to use them. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5296#comment:29> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #11664: Core Lint failure when building warp-3.2.2
by GHC 02 Mar '16

02 Mar '16

#11664: Core Lint failure when building warp-3.2.2 ---------------------------------------+--------------------------------- Reporter: anton.dessiatov | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 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: ---------------------------------------+--------------------------------- When building warp-3.2.2 with `-dcore-lint` the module Network.Wai.Handler.Warp.HTTP2.Worker fails to compile with Core Lint errors. Steps to reproduce (assuming that you have [http://haskellstack.org Stack] installed): 1. Download [https://hackage.haskell.org/package/warp-3.2.2/warp-3.2.2.tar.gz warp-3.2.2.tar.gz] from Hackage, extract it, and cd to that directory. 2. Run `echo "resolver: lts-5.5" > stack.yaml` and then `stack build --ghc-options -dcore-lint`. The text with exact error message is attached to this ticket. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11664> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #11665: Recent master fails to build attoparsec-0.13.0.1 with core lint failure
by GHC 02 Mar '16

02 Mar '16

#11665: Recent master fails to build attoparsec-0.13.0.1 with core lint failure ---------------------------------------+--------------------------------- Reporter: anton.dessiatov | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: 11664 Differential Rev(s): | Wiki Page: ---------------------------------------+--------------------------------- You might also like to see #11664 for some history. I have tried using current `master` 57b4c5524fcbf02f61dfc8d9395906dc7f50f048 to build current `attoparsec-0.13.0.1` on Ubuntu Linux 15.10 x86_64. The build fails with Core Lint error {{{ <no location info>: warning: In the type ‘Buffer -> Pos -> More -> a_aOwS -> IResult Text r_aOwT’ @ a_aOwS is out of scope }}} Attached comes full output of `cabal install attoparsec --with-ghc=<path- to-ghc> --verbose --ghc-options -dcore-lint`. The output is huge (57k lines) so I gzipped it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11665> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

GADTs and functional dependencies?
by Conal Elliott 02 Mar '16

02 Mar '16

Do GADTs and functional dependencies get along? I'm wondering why the following code doesn't type-check under GHC 7.10.3 and 8.1.20160224: > {-# OPTIONS_GHC -Wall #-} > {-# LANGUAGE GADTs, KindSignatures, MultiParamTypeClasses, FunctionalDependencies #-} > > module FundepGadt where > > class C a b | a -> b > > data G :: * -> * where > -- ... > GC :: C a b => G b -> G a > > instance Eq (G a) where > -- ... > GC b == GC b' = b == b' Error message: FundepGadt.hs:14:25: error: • Couldn't match type 'b1’ with 'b’ 'b1’ is a rigid type variable bound by a pattern with constructor: GC :: forall a b. C a b => G b -> G a, in an equation for '==’ at FundepGadt.hs:14:12 'b’ is a rigid type variable bound by a pattern with constructor: GC :: forall a b. C a b => G b -> G a, in an equation for '==’ at FundepGadt.hs:14:3 Expected type: G b Actual type: G b1 • In the second argument of '(==)’, namely 'b'’ In the expression: b == b' In an equation for '==’: (GC b) == (GC b') = b == b' • Relevant bindings include b' :: G b1 (bound at FundepGadt.hs:14:15) b :: G b (bound at FundepGadt.hs:14:6) I think the functional dependency does ensure that "b == b" is well-typed. In contrast, the following type-family version does type-check: > {-# OPTIONS_GHC -Wall #-} > {-# LANGUAGE GADTs, KindSignatures, TypeFamilies #-} > > module TyfamGadt where > > class C a where > type B a > > data G :: * -> * where > -- ... > GC :: C a => G (B a) -> G a > > instance Eq (G a) where > -- ... > GC b == GC b' = b == b' Thanks, - Conal

2 1

[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