December 2015 - ghc-tickets

[GHC] #11265: Internal error, using pattern synonym as instance head
by GHC 23 Dec '15

23 Dec '15

#11265: Internal error, using pattern synonym as instance head -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 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: -------------------------------------+------------------------------------- {{{!#hs {-# LANGUAGE PatternSynonyms, DataKinds #-} pattern A = True class F a instance F A }}} when loaded in ghci it results in an internal error {{{!#hs % g internal.hs GHCi, version 7.11.20151216: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( internal.hs, interpreted ) internal.hs:5:12: error: • GHC internal error: ‘A’ is not in scope during type checking, but it passed the renamer tcl_env of environment: [] • In the first argument of ‘F’, namely ‘A’ In the instance declaration for ‘F A’ Failed, modules loaded: none. Prelude> }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11265> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #11274: Confused type checker with typed holes and a missing instance (also panic)
by GHC 23 Dec '15

23 Dec '15

#11274: Confused type checker with typed holes and a missing instance (also panic) -------------------------------------+------------------------------------- Reporter: Xandaros | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- If your file contains a typed hole and a case where an instance is missing, the type checker will not find the missing instance and only report the hole. If -fdefer-typed-holes is set, this results in a panic. (Using ghci, the panic occurs when any definition of the module is being evaluated) Minimal working example: {{{#!hs {-# OPTIONS_GHC -fdefer-typed-holes #-} data Asd = Asd someHole = _asd missingInstance :: Asd -> Asd -> Bool missingInstance x y = x == y }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11274> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #9739: GHC 7.8 chokes on recursive classes
by GHC 23 Dec '15

23 Dec '15

#9739: GHC 7.8 chokes on recursive classes -------------------------------------+------------------------------------- Reporter: bitonic | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.3 checker) | Operating System: Keywords: | Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Difficulty: Unknown | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Type checking this makes GHC 7.8.3 loop: {{{#!hs {-# LANGUAGE MultiParamTypeClasses #-} module Foo where class Class3 a => Class1 a where class Class2 t a where class2 :: (Class3 t) => a -> m class (Class1 t, Class2 t t) => Class3 t where }}} Does not happen in 7.6.3. I think it's something to do with the `Class3` constraint appearing in `class2`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9739> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #10426: matchGroupArity panic with PatternSynonyms
by GHC 23 Dec '15

23 Dec '15

#10426: matchGroupArity panic with PatternSynonyms ---------------------------------------+--------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Linux Architecture: x86 | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | ---------------------------------------+--------------------------------- {{{#!hs {-# LANGUAGE PatternSynonyms, ViewPatterns, EmptyCase #-} pattern Id <- (id -> _) where }}} which gives: {{{#!hs % ghc -ignore-dot-ghci tmp.FbbzjZ48OO.hs [1 of 1] Compiling Main ( tmp.FbbzjZ48OO.hs, tmp.FbbzjZ48OO.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.10.0.20150316 for i386-unknown-linux): matchGroupArity Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10426> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #11244: Compiler plugins should not have visibility controlled by -package
by GHC 22 Dec '15

22 Dec '15

#11244: Compiler plugins should not have visibility controlled by -package -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 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: -------------------------------------+------------------------------------- The current way compiler plugins are recommended to be specified is by putting it in a package and then referring to the exported module name in the `-fplugin` flag. Consequently, the recommended way to use a plugin from Cabal is to put it in `build-depends`. For example, [https://hackage.haskell.org/package/ghc-typelits-natnormalise ghc- typelits-natnormalise] is used by [http://hackage.haskell.org/package /clash-prelude clash-prelude], whose [http://hackage.haskell.org/package /clash-prelude-0.10.4/clash-prelude.cabal build-depends] depends on it explicitly. There are numerous downsides to operating in this manner: 1. Cabal will always link in any library which is `build-depend`ed on, even if there is no runtime dependency on the package in question. For example, suppose the default `cabal-init` package with a `build-depends: ghc` and doesn't use it, you get: {{{ ezyang@sabre:~/Dev/labs/link$ cat Main.hs module Main where main :: IO () main = putStrLn "Hello, Haskell!" ezyang@sabre:~/Dev/labs/link$ cabal configure --enable-executable-dynamic; cabal build # elided ezyang@sabre:~/Dev/labs/link$ ldd dist/build/link/link | grep libHSghc libHSghc-7.10.2-JzwEp1oQ8kA7NFNTGk1ho5-ghc7.10.2.so => /srv/code/ghc-7.10.2/usr/lib/ghc-7.10.2/ghc_JzwEp1oQ8kA7NFNTGk1ho5/libHSghc-7.10.2-JzwEp1oQ8kA7NFNTGk1ho5-ghc7.10.2.so (0x00007f591f47a000) }}} That's terrible. And it's inflicted on every package which depends on a library that uses the plugin. The situation is better with static linking, since the linker can drop unreferenced object files; but we shouldn't be passing it to the linker in the first place. 2. It should be possible use a compiler plugin with a cross-compiler (e.g. GHCJS, etc.); unlike Template Haskell, the plugin must be written with the host compiler in mind. But the package database contains libraries compiled in the //target language//; whereas a compiler plugin must be compiled in the //host language//. It seems clear that using `-package` to bring a plugin into scope is highly undesirable. So what should we do? The necessary information to load a plugin is: 1. The package DB entry for the package it lives in (and information about all its transitive dependencies, because we may need to load code from them as well), 2. The actual module which contains the plugin. This leaves us with a number of options on the GHC end: 1. We could have a explicitly, IPID qualified method of specifying plugins. So, instead of saying `-fplugin ModuleName` and being at the mercy of what is exposed, you could say `-fplugin foo-0.1-xxxx:ModuleName` and as long as that package is usable (not ignored/broken) it would get loaded. 2. We could have a *completely separate* package database for plugins. You would control it using `-plugin-package` rather than `-package`; you don't even have to use the default system/user databases (which means that it might be possible to support a cross-compiler, although the details are fuzzy in my head). A benefit of this approach is that you can support the `-fplugin MyModule` mode of use, and have Cabal feed in the extra plugin package arguments to give meaning to this expression. An alternate command line interface (suggested by SPJ) would be that to load a plugin, you specify a path to the package database, package, and module in question, something like `-fplugin /path/to/package.conf/foo-0.1-xxxx.conf:MyPlugin` (one difficulty with this approach is that you may need multiple package databases to get this to work.) There would also be necessary Cabal adjustments, to get people to not put their plugins in `build-depends`, but a different dependency section, and how to have Cabal feed the IPID of the plugin to GHC. I'm happy to implement, but I'm looking for some consensus on what to do. (1) is easier to implement, but I dare say harder to integrate with Cabal. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11244> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

Re: [GHC] #1311: newtypes of unboxed types disallowed - documentation bug and/or feature request
by GHC 22 Dec '15

22 Dec '15

#1311: newtypes of unboxed types disallowed - documentation bug and/or feature request -------------------------------------+------------------------------------- Reporter: Isaac Dupree | Owner: osa1 Type: feature request | Status: new Priority: low | Milestone: ⊥ Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): So I think this turned out to be more complicated than we first thought (as usual). Richard, could you tell me if I'm going in the right direction? Here's what I did so far: {{{#!diff --- a/compiler/typecheck/TcTyClsDecls.hs +++ b/compiler/typecheck/TcTyClsDecls.hs @@ -1490,7 +1490,7 @@ tcGadtSigType doc name ty@(HsIB { hsib_vars = vars }) tcHsTyVarBndrs gtvs $ \ _ -> do { ctxt <- tcHsContext cxt ; btys <- tcConArgs DataType hs_details - ; ty' <- tcHsLiftedType res_ty + ; ty' <- tcHsOpenType res_ty ; field_lbls <- lookupConstructorFields name ; let (arg_tys, stricts) = unzip btys bound_vars = allBoundVariabless ctxt `unionVarSet` }}} Second change: {{{#!diff --- a/compiler/typecheck/TcHsType.hs +++ b/compiler/typecheck/TcHsType.hs @@ -1862,8 +1862,7 @@ tcDataKindSig :: Kind -> TcM [TyVar] -- We use it also to make up argument type variables for for data instances. -- Never emits constraints. tcDataKindSig kind - = do { checkTc (isLiftedTypeKind res_kind) (badKindSig kind) - ; span <- getSrcSpanM + = do { span <- getSrcSpanM ; us <- newUniqueSupply ; rdr_env <- getLocalRdrEnv ; let uniqs = uniqsFromSupply us @@ -1880,11 +1879,6 @@ tcDataKindSig kind mk_tv loc uniq occ kind = mkTyVar (mkInternalName uniq occ loc) kind -badKindSig :: Kind -> SDoc -badKindSig kind - = hang (ptext (sLit "Kind signature on data type declaration has non-* return kind")) - 2 (ppr kind) - {- Note [Avoid name clashes for associated data types] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ }}} Those are all for accepting this program: {{{#!haskell {-# LANGUAGE MagicHash, KindSignatures, GADTs #-} module Main where import GHC.Types import GHC.Prim import GHC.Exts newtype Blah :: TYPE 'Unlifted where Blah :: Int# -> Blah main = return () }}} For now I'm not trying to infer unlifted types, I'm trying to make cases with explicit kind signatures working. With these changes, GHC is failing with this panic: {{{ ghc-stage1: panic! (the 'impossible' happened) (GHC version 7.11.20151222 for x86_64-unknown-linux): ASSERT failed! file compiler/typecheck/TcTyClsDecls.hs, line 1630 }}} This is because we have some code that assume result types of ... I think GADTs? ... are lifted. (I think newtypes defined this way are type checked using GADT type checker?) Am I doing this right? How should I proceed after this point? I feel like I shouldn't lift these restrictions and instead I need some special cases for newtypes. Am I right? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1311#comment:12> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #11098: TH mishandles type variables that begin with an underscore
by GHC 22 Dec '15

22 Dec '15

#11098: TH mishandles type variables that begin with an underscore -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Template | Version: 7.10.2 Haskell | 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: -------------------------------------+------------------------------------- The following GHCi exchange was reported [https://github.com/goldfirere /th-desugar/pull/36 here] (you need not follow the link to understand this ticket, though). {{{ Prelude Language.Haskell.TH> runQ [d|foo :: forall _a . _a -> _a;foo x = x|] [SigD foo_6 (ForallT [PlainTV _a_5] [] (AppT (AppT ArrowT (WildCardT (Just _a_5))) (WildCardT (Just _a_5)))),FunD foo_6 [Clause [VarP x_7] (NormalB (VarE x_7)) []]] }}} The problem is that the quoted expression uses no wildcards, yet the TH output does. That quoted expression just uses a type variable that begins with an underscore. Such an expression was allowed in Haskell long before wildcards. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11098> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #10982: Warn about unused pattern variables in type families
by GHC 22 Dec '15

22 Dec '15

#10982: Warn about unused pattern variables in type families -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 7.11 Keywords: newcomer | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Now that we have wildcards in type families (#3699) I want to be warned about unused pattern variables in the same way I am warned about them at the term level. For example this should cause a warning that `b` is not used: {{{#!hs type family F a b type instance F a b = a }}} Prefixing unused variable with an underscore should suppress the warning: {{{#!hs type family F a b type instance F a _b = a }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10982> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #11225: Unable to provide type signature for pattern synonym
by GHC 22 Dec '15

22 Dec '15

#11225: Unable to provide type signature for pattern synonym -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple PatternSynonyms | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: patsyn/T11224 | Blocked By: Blocking: | Related Tickets: #11224 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{ {-# language PatternSynonyms , ViewPatterns #-} import Text.Read pattern PRead a <- (readMaybe -> Just a) }}} GHC infers the type correctly for `PRead` but it is impossible provide a signature. See #11224 for more discussion about why. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11225> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #10967: Release a new stm package on Hackage
by GHC 22 Dec '15

22 Dec '15

#10967: Release a new stm package on Hackage -------------------------------------+------------------------------------- Reporter: svenpanne | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries | Version: (other) | Keywords: stm | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Currently, the latest stm package on Hackage (2.4.4) doesn't compile with GHC HEAD (see e.g. https://travis-ci.org/haskell- opengl/OpenGL/jobs/85320391), which makes testing of various other packages with HEAD imposiible. Things seem to be fixed in git already, can we have a new release of stm? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10967> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8