December 2016 - ghc-tickets

[GHC] #8460: Annotation reification with types in TH
by GHC 07 Dec '16

07 Dec '16

#8460: Annotation reification with types in TH -------------------------------------------+------------------------------- Reporter: errge | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 hour) | Type of failure: Blocked By: | None/Unknown Related Tickets: #8397 | Test Case: | Blocking: -------------------------------------------+------------------------------- The attached patch adds two simple helper functions to support typed reification of annotations. This was not in the original #8397 patch only because the typed branch was not merged at that time. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8460> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #9813: Error when reifying type constructor
by GHC 07 Dec '16

07 Dec '16

#9813: Error when reifying type constructor -------------------------------------+------------------------------------- Reporter: owst | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- The following code works under ghc-7.6.3 and template-haskell-2.8.0.0: {{{#!hs {-# LANGUAGE TemplateHaskell #-} data Huh = ThisDefinitely | UsedToWork constructorNames :: String constructorNames = $(do ty <- reify ''Huh let showCon (NormalC n _) = nameBase n strs = case ty of (TyConI (DataD _ _ _ cons _)) -> map showCon cons return . LitE . StringL $ concat strs) main = putStrLn constructorNames }}} Printing the following at compile time: {{{ [1 of 1] Compiling Main ( Main.hs, Main.o ) Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading package array-0.4.0.1 ... linking ... done. Loading package deepseq-1.3.0.1 ... linking ... done. Loading package containers-0.5.0.0 ... linking ... done. Loading package pretty-1.1.1.0 ... linking ... done. Loading package template-haskell ... linking ... done. Linking Main ... }}} and then successfully executing: {{{ $ ./Main ThisDefinitelyUsedToWork }}} However, using ghc 7.8.3/template-haskell-2.9.0.0 I get the following compile error: {{{ [1 of 1] Compiling Main ( Main.hs, Main.o ) Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading package array-0.5.0.0 ... linking ... done. Loading package deepseq-1.3.0.2 ... linking ... done. Loading package containers-0.5.5.1 ... linking ... done. Loading package pretty-1.1.1.1 ... linking ... done. Loading package template-haskell ... linking ... done. Main.hs:8:22: ‘Huh’ is not in the type environment at a reify In the splice: $(do { ty <- reify ''Huh; let showCon (NormalC n _) = ... ....; return . LitE . StringL $ concat strs }) }}} Is this expected? I couldn't see anything in the GHC release notes to suggest this should no longer work. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9813> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 46

[GHC] #12455: Compact Regions
by GHC 07 Dec '16

07 Dec '16

#12455: Compact Regions -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: task | Status: new Priority: high | Milestone: 8.2.1 Component: Runtime | Version: 8.1 System | 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 going to use this task to keep track of what we still need to do around compact regions before 8.2.1, and so I have somewhere to hang diffs. Here's the current ToDo list: * compaction should be interruptible by GC, otherwise we block a multithreaded program while compacting (I know how to do this and have a prototype, just need to finish it). * Make it work with profiling * We should have an API that doesn't require specifying a size, just `compact :: NFData a => a -> IO (Compact a)` * libraries/compact/tests failures with `EXTRA_HC_OPTS="-debug -with- rtsopts=-DS"` * Do we need both `totalW` and `totalDataW`? It looks like one of them is redundant to me. * What happens if we try to compact something that refers to a large block? One larger than a megablock? * Improve comments -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12455> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

Re: [GHC] #12914: Port SplitSections to Windows
by GHC 07 Dec '16

07 Dec '16

#12914: Port SplitSections to Windows -------------------------------------+------------------------------------- Reporter: olsner | Owner: Type: task | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Linking) | Resolution: duplicate | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 8405 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * status: new => closed * resolution: => duplicate Comment: Duplicate of #12913 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12914#comment:2> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12404: Document version availability for each language extension
by GHC 07 Dec '16

07 Dec '16

#12404: Document version availability for each language extension -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature | Status: new request | Priority: normal | Milestone: 8.2.1 Component: Documentation | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Documentation Unknown/Multiple | bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- A certain amount of "historical" information about language extensions is of sufficient practical utility to deserve a place in the GHC documentation. I believe that the documentation for each language extension should include 1. The GHC version in which it first appeared. 2. Any major changes that have been made to the extension since the previous major-major version. For example, the GHC 8.x.x documentation for any given language extension should include any major changes to it since 7.0.1. At present, the only way I see to get this information is to dig through previous versions of the documentation and change logs, which is rather inefficient. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12404> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #12224: Replace placeHolderPunRhs with a PlaceHolder value
by GHC 06 Dec '16

06 Dec '16

#12224: Replace placeHolderPunRhs with a PlaceHolder value -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 (Parser) | 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: -------------------------------------+------------------------------------- At the moment `placeHolderPunRhs` is defined as {{{#!hs placeHolderPunRhs :: LHsExpr RdrName -- The RHS of a punned record field will be filled in by the renamer -- It's better not to make it an error, in case we want to print it when debugging placeHolderPunRhs = noLoc (HsVar pun_RDR) pun_RDR = mkUnqual varName (fsLit "pun-right-hand-side") }}} Rather use a type of `PostRn id (LHsExpr id)` where this is used. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12224> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #11757: Turn on (and require) C99/C11 mode by default
by GHC 06 Dec '16

06 Dec '16

#11757: Turn on (and require) C99/C11 mode by default -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Build System | Version: 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: -------------------------------------+------------------------------------- GCC 5.x started defaulting to C99 (or rather gnu99 mode), while Clang has been defaulting to C99 (or even C11) for a bit longer, as has Apple's patched GCC. So we should try to consistently turn on (if needed) C99 (or C11) support for all compilers supported by GHC, and adapt the code-base to expect C99 compliance (which probably allows us to get rid of a couple of compat-CPP and make the C code more idiomatic and readable in the process...). GNU Autoconf provides a `AC_PROG_CC_C99` which figures out what's needed to have the compiler turn on C99 support, but we need to integrate that with out Requiring C99 will effectively rule out GCC 3.x (which is old enough that we can drop support for that), and possibly also GCC < 4.3 at some point (for reference, even Debian 6 Squeeze didn't have GCC 4.2 anymore), see also https://gcc.gnu.org/c99status.html -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11757> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #11493: Merge compact normal forms
by GHC 06 Dec '16

06 Dec '16

#11493: Merge compact normal forms -------------------------------------+------------------------------------- Reporter: bgamari | Owner: ezyang Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: | Version: 7.10.3 libraries/compact | 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: -------------------------------------+------------------------------------- Merge Yang and Campagna's [[Compact Normal Forms work|http://ezyang.com/compact.html]] There are several pieces to this, * Types and construction logic for compact regions (see Phab:D1264) * Serialization and fixup logic (currently also in Phab:D1264) * Striped allocator for heap sharing between processes (allocator in Phab:D1434, CNF support in Phab:D1435). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11493> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #4471: Incorrect Unicode output on Windows Console
by GHC 06 Dec '16

06 Dec '16

#4471: Incorrect Unicode output on Windows Console -------------------------------------+------------------------------------- Reporter: sankeld | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.12.3 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: Incorrect result | Test Case: at runtime | Blocked By: | Blocking: Related Tickets: #11394 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.2.1 => Comment: De-milestoning due to lack of progress. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4471#comment:28> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #11557: Unbundle Cabal from GHC
by GHC 06 Dec '16

06 Dec '16

#11557: Unbundle Cabal from GHC -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: libraries | Version: 8.1 (other) | 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: -------------------------------------+------------------------------------- Recently, Duncan made it so that GHC proper does not depend on Cabal (so it is just ghc-pkg that is the user-facing executable which links against Cabal). We should now seriously consider unbundling Cabal from GHC, so that the default global database we provide does NOT include Cabal. Pros: * Distributions will be more likely to take point version releases to Cabal, as they no longer have to finesse updating Cabal without updating GHC as they have now * Stack is (improperly) coupling the version of Cabal they build with the release of GHC; while they should fix this, unbundling Cabal would also give them more flexibility with picking LTS packages. Cons: * Bootstrapping Cabal/cabal-install becomes modestly harder. Fortunately, cabal-install is already pretty obnoxious to bootstrap, so SOP is to just distribute binaries for this, in which case things are as easy as before. * We wouldn't be strictly adhering to the Cabal spec, which requires that the compiler always be able to build the Setup executable. * ghc-pkg would have to be statically linked -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11557> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4