- ghc-tickets - Haskell.org

Re: [GHC] #7938: Unbound kind variable can appear in RHS of associated type
by GHC 05 Sep '17

05 Sep '17

#7938: Unbound kind variable can appear in RHS of associated type -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: GHC accepts | Test Case: indexed- invalid program | types/should_fail/T7938 Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- Comment (by Ryan Scott <ryan.gl.scott@…>): In [changeset:"0829821a6b886788a3ba6989e57e25a037bb6d05/ghc" 0829821a/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="0829821a6b886788a3ba6989e57e25a037bb6d05" Implicitly bind kind variables in type family instance RHSes when it's sensible Summary: Before, there was a discrepancy in how GHC renamed type synonyms as opposed to type family instances. That is, GHC would accept definitions like this one: ```lang=haskell type T = (Nothing :: Maybe a) ``` However, it would not accept a very similar type family instance: ```lang=haskell type family T :: Maybe a type instance T = (Nothing :: Maybe a) ``` The primary goal of this patch is to bring the renaming of type family instances up to par with that of type synonyms, causing the latter definition to be accepted, and fixing #14131. In particular, we now allow kind variables on the right-hand sides of type (and data) family instances to be //implicitly// bound by LHS type (or kind) patterns (as opposed to type variables, which must always be explicitly bound by LHS type patterns only). As a consequence, this allows programs reported in #7938 and #9574 to typecheck, whereas before they would have been rejected. Implementation-wise, there isn't much trickery involved in making this happen. We simply need to bind additional kind variables from the RHS of a type family in the right place (in particular, see `RnSource.rnFamInstEqn`, which has undergone a minor facelift). While doing this has the upside of fixing #14131, it also made it easier to trigger #13985, so I decided to fix that while I was in town. This was accomplished by a careful blast of `reportFloatingKvs` in `tcFamTyPats`. Test Plan: ./validate Reviewers: simonpj, goldfire, austin, bgamari Reviewed By: simonpj Subscribers: rwbarton, thomie GHC Trac Issues: #13985, #14131 Differential Revision: https://phabricator.haskell.org/D3872 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7938#comment:3> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13988: GADT constructor with kind equality constraint quantifies unused existential type variables
by GHC 05 Sep '17

05 Sep '17

#13988: GADT constructor with kind equality constraint quantifies unused existential type variables -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Type checker) | Keywords: TypeInType | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Reproducible with GHC 8.0.1., 8.0.2, 8.2.1, or HEAD (but I'll use GHC 8.2.1 to show the results of `:type +v`): {{{ $ /opt/ghc/8.2.1/bin/ghci GHCi, version 8.2.0.20170704: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci λ> :set -XTypeInType -XGADTs -fprint-explicit-foralls λ> import Data.Kind λ> data Foo (a :: k) where MkFoo :: (k ~ Type) => Foo (a :: k) λ> :type +v MkFoo MkFoo :: forall k1 (a :: k1) k2 (k3 :: k2). k1 ~ * => Foo a }}} Note that `MkFoo` quantifies two extra existential type variables, `k2` and `k3` which are completely unused! Note that this does not occur if the `MkFoo` constructor uses an explicit `forall`: {{{ λ> :set -XScopedTypeVariables λ> data Foo (a :: k) where MkFoo :: forall k (a :: k). (k ~ Type) => Foo (a :: k) λ> :type +v MkFoo MkFoo :: forall k (a :: k). k ~ * => Foo a }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13988> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #14181: make test WAY=xxx broken
by GHC 05 Sep '17

05 Sep '17

#14181: make test WAY=xxx broken -------------------------------------+------------------------------------- Reporter: angerman | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 | Type of failure: None/Unknown (amd64) | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- It seems like running {{{ make test WAY=someWay }}} is broken. Looking at the `runtest.py`, it seems that we parse the arguments to the test driver before reading the configuration file (e.g. `config/ghc`), and thus the `--way` flags arguments are not available. E.g. the way options get populated, once the `--config-file` argument is processed. But the argument parser seems to be eager and as such the handling of the `--config-file` happens *after* all of the arguments have been parsed. Therefore the set of available `--way`s are always the empty set. I don't know if python2 was lazy here. But with `python3` using `--way` seems impossible. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14181> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #13105: Allow type families in RuntimeReps
by GHC 05 Sep '17

05 Sep '17

#13105: Allow type families in RuntimeReps -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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: -------------------------------------+------------------------------------- Conal Elliott provided me with this puzzle: {{{ type family RepRep a ∷ RuntimeRep class HasRep a where type Rep a ∷ TYPE (RepRep a) repr ∷ a → Rep a abst ∷ Rep a → a type instance RepRep Int = IntRep instance HasRep Int where type Rep Int = Int# abst n = I# n repr (I# n) = n }}} I think we should accept. However, doing so (even with my solution to #12809 complete) is hard, because we frequently consult a kind in order to determine a runtime representation. When that kind is `TYPE (RepRep Int)`, the code generator throws up its arms in despair. The solution here is either to teach the code generator how to normalise types (requiring propagating the `FamInstEnvs`) or to do a whole-program transformation at some point (zonker? desugarer? maybe we can wait until !CorePrep or even unarisation?) to change ids whose types have kinds like `TYPE (RepRep Int)` into ids with types with kinds like `TYPE IntRep`. But I don't want to let this hold me up at the moment, so I'm posting here as a reminder to revisit this problem. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13105> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #12708: RFC: Representation polymorphic Num
by GHC 04 Sep '17

04 Sep '17

#12708: RFC: Representation polymorphic Num -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Core | Version: 8.0.1 Libraries | 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: -------------------------------------+------------------------------------- I can create a GHC proposal for this but I need a sanity check first {{{#!hs import Prelude hiding (Num (..)) import qualified Prelude as P import GHC.Prim import GHC.Types class Num (a :: Type k) where (+) :: a -> a -> a (-) :: a -> a -> a (*) :: a -> a -> a negate :: a -> a abs :: a -> a signum :: a -> a fromInteger :: Integer -> a instance Num Int# where (+) :: Int# -> Int# -> Int# (+) = (+#) (-) :: Int# -> Int# -> Int# (-) = (-#) (*) :: Int# -> Int# -> Int# (*) = (*#) negate :: Int# -> Int# negate = negateInt# ... fromInteger :: Integer -> Int# fromInteger (fromInteger -> I# int) = int instance Num Double# where (+) :: Double# -> Double# -> Double# (+) = (+##) (-) :: Double# -> Double# -> Double# (-) = (-##) (*) :: Double# -> Double# -> Double# (*) = (*##) negate :: Double# -> Double# negate = negateDouble# ... fromInteger :: Integer -> Double# fromInteger (fromInteger -> D# dbl) = dbl }}} Note how the `fromInteger` views aren't qualified? That's because we can branch on the kind and all of a sudden, all instances of old `Num` are instances of our `Num` {{{#!hs instance P.Num a => Num (a :: Type) where (+) = (P.+) (-) = (P.-) (*) = (P.*) negate = P.negate abs = P.abs signum = P.signum fromInteger = P.fromInteger }}} ---- Same with `Show` etc. etc. {{{#!hs class Show (a :: TYPE k) where show :: (a :: TYPE k) -> String instance P.Show a => Show (a :: Type) where show :: (a :: Type) -> String show = P.show instance Show Int# where show :: Int# -> String show int = show (I# int) instance Show Double# where show :: Double# -> String show dbl = show (D# dbl) }}} ---- What effects would this have? They are even printed the same by default {{{#!hs >>> :kind Prelude.Num Prelude.Num :: * -> Constraint >>> :kind Main.Num Main.Num :: * -> Constraint >>> :set -fprint-explicit-runtime-reps >>> :kind Main.Num Main.Num :: TYPE k -> Constraint }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12708> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 31

[GHC] #14183: ghc.exe: addLibrarySearchPath error
by GHC 04 Sep '17

04 Sep '17

#14183: ghc.exe: addLibrarySearchPath error ----------------------------------------+--------------------------------- Reporter: vagarenko | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- Recently I've removed Haskell Platform 8.0.1 and installed new Platform 8.2.1 Since then, when compiling a module GHC sometimes spits the following messages: {{{ ghc.exe: addLibrarySearchPath: C:\Program Files\Haskell Platform\8.0.1\mingw\lib (Win32 error 3): The system cannot find the path specified. }}} dozens of times in a row. But the compilation succeeds. The directory `C:\Program Files\Haskell Platform\8.0.1\` doesn't exist on my machine. I haven't figured out when exactly this happens but it seems to happen only when the module has Template Haskell splices in it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14183> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #14184: Examples with language extensions
by GHC 03 Sep '17

03 Sep '17

#14184: Examples with language extensions -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Documentation | Version: 8.2.1 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: -------------------------------------+------------------------------------- Are we okay with examples in the GHC user guide uses language extensions? The documentation has [https://downloads.haskell.org/~ghc/master/users- guide/glasgow_exts.html#record-constructors this code] {{{#!hs inc :: Counter a -> Counter a inc (NewCounter x i d t) = NewCounter { _this = i x, _inc = i, _display = d, tag = t } }}} which could be written {{{#!hs inc :: Counter a -> Counter a inc NewCounter{..} = NewCounter{ _this = _inc _this, .. } }}} if we're okay with that tradeoff. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14184> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #13956: ghc panic compiling lame-0.1.1
by GHC 03 Sep '17

03 Sep '17

#13956: ghc panic compiling lame-0.1.1 -------------------------------------+------------------------------------- Reporter: uznx | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1-rc3 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Compiling the package lame-0.1.1 using cabal, with profiling: [2 of 2] Compiling Codec.Audio.LAME ( Codec/Audio/LAME.hs, dist/build/Codec/Audio/LAME.p_o ) ghc: panic! (the 'impossible' happened) (GHC version 8.2.0.20170704 for x86_64-unknown-linux): Simplifier ticks exhausted When trying UnfoldingDone lvl_soT9 To increase the limit, use -fsimpl-tick-factor=N (default 100) If you need to do this, let GHC HQ know, and what factor you needed To see detailed counts use -ddump-simpl-stats Total ticks: 504681 Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1133:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1137:37 in ghc:Outputable pprPanic, called at compiler/simplCore/SimplMonad.hs:199:31 in ghc:SimplMonad Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug This is a regression; the package compiles fine with GHC 8.0.2 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13956> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #14167: GHC often depicts H98 datatypes as GADTs when it shouldn't
by GHC 02 Sep '17

02 Sep '17

#14167: GHC often depicts H98 datatypes as GADTs when it shouldn't -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Keywords: GADTs, | Operating System: Unknown/Multiple TemplateHaskell | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- (Spun off from Phab:D3880.) There are at least a couple of points in the GHC codebase where poor decisions are made regarding whether to depict a datatype using H98 syntax or GADT syntax. In particular: 1. When reifying a datatype in Template Haskell, some complicated heuristics are used to determine whether a datatype is reified with `(Rec)GadtC` or not (see `Note [Reifying GADT data constructors]` in `TcSplice` for the horrifying details). But these heuristics are far from perfect, as they will cause some vanilla datatypes to be reified as GADTs (e.g., `data T a = (a ~ Int) => MkT`). 2. When pretty-printing a datatype (for instance, via the `:info` command in GHCi), GHC also chooses to sometimes depict vanilla datatypes as GADTs. For instance: {{{ λ> :set -XExistentialQuantification λ> data Foo a = Show a => Foo λ> :i Foo type role Foo nominal data Foo a where Foo :: Show a => Foo a }}} `Foo` is depicted as a GADT, despite the fact that we didn't use GADT syntax. There might be other places in the code that exhibit these symptoms too—we should take a closer look. I use the phrase "poor decisions" above since GHC really does have the right info it needs to make the correct decisions. That info is in the form of the `isGadtSyntaxTyCon`, which conveniently recalls whether a datatype was declared with GADT syntax or not. With this, we should be able to eliminate the flawed heuristics that GHC is currently using and accurately depict datatypes the way users wrote them. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14167> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #14112: bang patterns on pattern synonyms? (left vs right hand sides)
by GHC 02 Sep '17

02 Sep '17

#14112: bang patterns on pattern synonyms? (left vs right hand sides) -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 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: -------------------------------------+------------------------------------- I'm trying to define my own fancy strict maybe types, and so i've written some pattern synonyms to wrap them up. imagine my surprise when i find i can write bang patterns on the *right* hand side, but not the left hand! {{{ data MyMaybe a = JustC a | NothingC pattern MyJust :: a -> MyMaybe a -- pattern MyJust !a = JustC a -- this fails pattern MyJust a = JustC !a -- this is fine }}} is this deliberate or a leakage of how desugaring works? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14112> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14