April 2015 - ghc-tickets

Re: [GHC] #3919: Or-patterns as GHC extension
by GHC 21 Apr '15

21 Apr '15

#3919: Or-patterns as GHC extension -------------------------------------+------------------------------------- Reporter: BjornEdstrom | Owner: Type: feature request | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by sergv): * cc: sergv (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3919#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7672: boot file entities are sometimes invisible and are not (semantically) unified with corresponding entities in implementing module
by GHC 21 Apr '15

21 Apr '15

#7672: boot file entities are sometimes invisible and are not (semantically) unified with corresponding entities in implementing module -------------------------------------+------------------------------------- Reporter: skilpat | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler (Type | Version: 7.4.2 checker) | Keywords: backpack Resolution: | Architecture: x86_64 Operating System: Linux | (amd64) Type of failure: GHC rejects | Test Case: valid program | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Changes (by simonpj): * owner: => ezyang Comment: I agree. Just remove it and see. It looks outright wrong to me. Simon -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7672#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7672: boot file entities are sometimes invisible and are not (semantically) unified with corresponding entities in implementing module
by GHC 21 Apr '15

21 Apr '15

#7672: boot file entities are sometimes invisible and are not (semantically) unified with corresponding entities in implementing module -------------------------------------+------------------------------------- Reporter: skilpat | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler (Type | Version: 7.4.2 checker) | Keywords: backpack Resolution: | Architecture: x86_64 Operating System: Linux | (amd64) Type of failure: GHC rejects | Test Case: valid program | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Comment (by ezyang): The reason this occurs is when we process imports in `rnImportDecl`, we filter out any identifiers which come from a self-boot: {{{ let gbl_env = mkGlobalRdrEnv (filterOut from_this_mod gres) }}} So these identifiers never get added to the GlobalRdrEnv, and thus aren't brought into scope. I don't know what happens if you remove that `filterOut`. It comes from some very old code. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7672#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10331: Accept HsSyn in splices and generate it in quotes (ghc-api)
by GHC 20 Apr '15

20 Apr '15

#10331: Accept HsSyn in splices and generate it in quotes (ghc-api) -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature | Status: new request | Milestone: Priority: low | Version: 7.11 Component: Template | Operating System: Unknown/Multiple Haskell | Type of failure: None/Unknown Keywords: | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- I propose a language pragma `GhcTemplateHaskell`, which, when enabled, causes Template Haskell splices to accept `HsSyn` return values, and causes TH quotes to return `HsSyn` trees. Users of `GhcTemplateHaskell` would stop using the `template-haskell` library and just directly manipulate the frontend ASTs using the `ghc-api`. Given our ghc-api track record, you would probably not be able to write code using this without having it break every GHC release. However, clients who are willing to track GHC development would reap the following benefits: 1. All syntax in Haskell would be supported in quotes; the AST would never lag behind. Additionally, you could use the ghc-api parser to parse Haskell code to be returned in a splice. (#2041) 2. Locations from quoting would be preserved. (Problem 2 of #10330) I don't think this would be difficult to implement, but it definitely could be a ball of wax. I broke this proposal off from #2041. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10331> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #10327: Devise workaround for how infinite types prevent closed type family reduction
by GHC 20 Apr '15

20 Apr '15

#10327: Devise workaround for how infinite types prevent closed type family reduction -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.10.1 Component: Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Suppose we have {{{ data a :+: b type family Inj x y where Inj a a = True Inj b (b :+: c) = False }}} When we try to reduce `Inj f (f :+: g)`, it looks like we should just use the second equation. Instead, we fail to reduce. This is because GHC is worried about the possibility of the first equation firing, in the event that `f ~ (f :+: g)`. This fact can happen only if `f` is infinitely large. On the surface, this seems impossible, but shenanigans in this area can cause `unsafeCoerce`. See #8162. I don't see an easy way to fix this, but the fact that GHC can't cope (well) with this example tells me something is wrong. Here is one idea of how to proceed: If we somehow ensure at reduction time that `f` is finite, we're OK. If we need finiteness in terms, we use `deepseq`. Can we do this in types? I tentatively say "yes". Imagine the following type family: {{{ type family Seq (x :: a) (y :: b) :: b type instance Seq True y = y type instance Seq False y = y }}} To reduce, say, {{{b `Seq` 5}}}, we'd need to know concretely what `b` is. We can then build `Deepseq` similarly to how `deepseq` at the term level works. The closed type family mechanism could then detect cases like `Inj`, where the whole infinite-type thing is causing trouble. (I conjecture that detecting this is not hard, as there's a specific line in the `Unify` module that triggers in the worry-about-infinite-types case.) In the case of `Inj`, something like `Inj f (f :+: g)` would reduce to {{{f `Deepseq` False}}}. Note that the call to `Seq` wouldn't be written in the closed type family definition, but would be inserted during reduction as appropriate. This solution is ugly. And it requires magic to define `Seq` in types (we need an instance for every type!) and weird magic in closed type family reduction. The definition of `Deepseq` might also benefit from being magical. It would be annoying to explain to users, but no more so than the current crazy story. In general, I don't like this idea much, but I do think it would work. In any case, this ticket is mainly to serve as a placeholder for any future thoughts in this direction. It's quite annoying to have the specter of infinite types cripple otherwise-sensible closed type families. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10327> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #8928: 64-bit statically linked binary consumes all memory while spinning on 'SIGVTALRM's
by GHC 20 Apr '15

20 Apr '15

#8928: 64-bit statically linked binary consumes all memory while spinning on 'SIGVTALRM's ----------------------------------+---------------------------------- Reporter: cswarth | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: Runtime crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+---------------------------------- I actually have no idea if this is a haskell bug or not, but since the earlier reported symptoms are similar, and the "pandoc" program is compiled with GHC, I thought I would report it here as well. This situation sounds exactly like [https://ghc.haskell.org/trac/ghc/ticket/7344 this bug] reported 17 months ago. Symptoms are 'pandoc --version' hangs and consumes memory until the process eventually dies with an OOM error. This seems to only happen when LC_ALL is set in the environment, and only when running the statically linked pandoc. {{{ $ uname -a Linux server 3.5.0-43-generic #66~precise1-Ubuntu SMP Thu Oct 24 14:52:23 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux $ wget https://s3.amazonaws.com/rstudio-buildtools/pandoc-1.12.3.zip $ unzip pandoc-1.12.3.zip $ file pandoc-1.12.3/linux/debian/x86_64/pandoc pandoc-1.12.3/linux/debian/x86_64/pandoc: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), statically linked, for GNU/Linux 2.6.15, BuildID[sha1]=0x9bc69f51b7c213cf58e9f8692f4b46f9f05fb723, not stripped $ LC_ALL=C strace -e trace=open,close pandoc-1.12.3/linux/debian/x86_64/pandoc --version open("/usr/lib/gconv/gconv-modules.cache", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/lib/gconv/gconv-modules", O_RDONLY) = -1 ENOENT (No such file or directory) --- SIGVTALRM (Virtual timer expired) @ 0 (0) --- --- SIGVTALRM (Virtual timer expired) @ 0 (0) --- --- SIGVTALRM (Virtual timer expired) @ 0 (0) --- --- SIGVTALRM (Virtual timer expired) @ 0 (0) --- ^C--- SIGINT (Interrupt) @ 0 (0) --- }}} Note this problem does not occur if I run an older dynamically linked pandoc under the same circumstances. {{{ $ /usr/bin/pandoc --version pandoc 1.9.1.1 Compiled with citeproc-hs 0.3.4, texmath 0.6.0.3, highlighting-kate 0.5.0.5. Syntax highlighting is supported for the following languages: Actionscript, Ada, Alert, Alert_indent, Apache, Asn1, Asp, Awk, Bash, Bibtex, Boo, C, Changelog, Clojure, Cmake, Coffeescript, Coldfusion, Commonlisp, Cpp, Cs, Css, D, Diff, Djangotemplate, Doxygen, Dtd, Eiffel, ... }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8928> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #10314: ApiAnnotations: mkHsForAllTy discards parens
by GHC 20 Apr '15

20 Apr '15

#10314: ApiAnnotations: mkHsForAllTy discards parens -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple ApiAnnotations | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The code for `HsForAllTy` is {{{#!hs mkHsForAllTy exp tvs ctxt ty = HsForAllTy exp extra (mkHsQTvs tvs) cleanCtxt ty where -- Separate the extra-constraints wildcard when present (cleanCtxt, extra) | (L l HsWildcardTy) <- ignoreParens (last (unLoc ctxt)) = (init `fmap` ctxt, Just l) | otherwise = (ctxt, Nothing) ignoreParens (L _ (HsParTy ty)) = ty ignoreParens ty = ty }}} The process of cleaning the context calls `ignoreParens` which strips out the `HsParTy`. In the process the `AnnOpenP` and `AnnCloseP` attached to this are discarded. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10314> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #7695: Hang when locale-archive and gconv-modules are not there
by GHC 20 Apr '15

20 Apr '15

#7695: Hang when locale-archive and gconv-modules are not there -------------------------------------+------------------------------------- Reporter: hpd | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.10.2 Component: None | Version: 7.8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime crash | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #8977 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): See other dups (beyond #10298): #8977, #8928 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7695#comment:16> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9745: qual_pkg panic with template haskell
by GHC 20 Apr '15

20 Apr '15

#9745: qual_pkg panic with template haskell -------------------------------------+------------------------------------- Reporter: luite | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- I'm updating some things that use Template Haskell to derive lenses to work with GHC HEAD, but I'm getting the following error. My `cabal- install` a fresh build from the master branch of the `cabal` repository. {{{ src/Lib.hs:11:1:ghc: panic! (the 'impossible' happened) (GHC version 7.9.20141029 for x86_64-unknown-linux): qual_pkg lens-4.5.0.0.1 }}} lenstest.cabal {{{ name: lenstest version: 0.1.0.0 license-file: LICENSE author: Luite Stegeman maintainer: stegeman(a)gmail.com build-type: Simple cabal-version: >=1.10 library build-depends: base >= 4.8 && < 4.9, lens >= 4.5 exposed-modules: Lib default-language: Haskell2010 hs-source-dirs: src }}} src/Lib.hs: {{{#!hs {-# LANGUAGE TemplateHaskell #-} module Lib where import Control.Lens data XY = X Int | Y String makeLenses ''XY makePrisms ''XY }}} The `lens` and `free` packages need to be patched to work with the latest GHC, because of a conflict with `Data.Bifunctor`. I've attached updated version that use `PackageImports` to get the module from `bifunctors` as a workaround. Use {{{ cabal install --allow-newer }}} to install, since some dependencies have too restrictive upper bounds. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9745> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

Re: [GHC] #2041: Allow splicing in concrete syntax
by GHC 20 Apr '15

20 Apr '15

#2041: Allow splicing in concrete syntax -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: feature request | Status: new Priority: normal | Milestone: ⊥ Component: Template Haskell | Version: 6.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by ezyang): I decided to record this alternate proposal here: #10331 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2041#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0