- ghc-tickets - Haskell.org

[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 23 Dec '15

23 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 23 Dec '15

23 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 23 Dec '15

23 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 23 Dec '15

23 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

[GHC] #11275: :kind! doesn't reduce type families with poly-kinded return kinds
by GHC 22 Dec '15

22 Dec '15

#11275: :kind! doesn't reduce type families with poly-kinded return kinds -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.10.3 Keywords: | 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: -------------------------------------+------------------------------------- Originally discovered [https://mail.haskell.org/pipermail/ghc- devs/2015-December/010831.html here], here is a simplified example: {{{ $ ghci GHCi, version 7.10.3: http://www.haskell.org/ghc/ :? for help λ> :set -XPolyKinds -XTypeFamilies λ> type family Hm :: k where Hm = Int λ> :kind! Hm Hm :: k = Hm }}} Giving `Hm` a monomorphic return kind of `*` makes it work with `:kind!`: {{{ $ ghci GHCi, version 7.10.3: http://www.haskell.org/ghc/ :? for help λ> :set -XTypeFamilies λ> type family Hm :: * where Hm = Int λ> :kind! Hm Hm :: * = Int }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11275> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #11147: Linker errors related to response files change
by GHC 22 Dec '15

22 Dec '15

#11147: Linker errors related to response files change -------------------------------------+------------------------------------- Reporter: waern | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Build System | Version: 7.11 Keywords: | Operating System: Linux Architecture: x86 | Type of failure: Building GHC | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Hi, Building GHC HEAD in Nix on Linux currently fails with linker errors. See https://github.com/NixOS/nixpkgs/issues/10752 The problem goes away if one reverts GHC commit 296bc70b5ff6c853f2782e9ec5aa47a52110345e. I don't know what the issue is, and I can't be 100% sure it's really a GHC problem and not a Nix one, but I thought it best to record this here. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11147> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #11256: ghc --make reports bad import errors too eagerly
by GHC 22 Dec '15

22 Dec '15

#11256: ghc --make reports bad import errors too eagerly -------------------------------------+------------------------------------- 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: -------------------------------------+------------------------------------- Consider this A.hs file, with a valid header (no B.hs file) and a syntax error: {{{ module A where import B = as7df89a235r a23jk @A#$(&#$A }}} We get different behavior when one-shot compiling and make compiling: {{{ ezyang@sabre:~$ ghc -c A.hs A.hs:4:1: parse error on input `=' ezyang@sabre:~$ ghc --make A.hs A.hs:2:8: Could not find module `B' Use -v to see a list of the files searched for. }}} I feel like the `--make` error is wrong, and we shouldn't actually complain that an import is missing until we build it. But it cuts both ways; if you have a big module graph and you try to `--make`, currently `--make` will report instantaneously if any import is wrong; if we changed this behavior, `--make` would chug along until it actually tried to compile the offending file. It's easy to fix and I can easily submit a patch for it, if people think we should defer the error. Doing this will also let me remove a grievous hack from my fix to #11244. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11256> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6