December 2016 - ghc-tickets

[GHC] #12911: Levity polymorphism check eliminates non-levity-polymorphic data constructor
by GHC 19 Dec '16

19 Dec '16

#12911: Levity polymorphism check eliminates non-levity-polymorphic data constructor -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple LevityPolymorphism | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When I say {{{ data X where MkX :: forall (a :: TYPE r). (a -> a) -> X }}} I get {{{ • A representation-polymorphic type is not allowed here: Type: a Kind: TYPE r • In the definition of data constructor ‘MkX’ In the data type declaration for ‘X’ }}} But that's silly, because the type is not levity-polymorphic! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12911> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

Re: [GHC] #5654: Profiling semantics bug
by GHC 18 Dec '16

18 Dec '16

#5654: Profiling semantics bug -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: closed Priority: low | Milestone: 8.2.1 Component: Profiling | Version: 7.2.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | profiling/should_run/scc004 Blocked By: | Blocking: Related Tickets: #10007 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5654#comment:21> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12992: Language.Haskell.TH doesn't reexport everything from Language.Haskell.TH.Lib
by GHC 18 Dec '16

18 Dec '16

#12992: Language.Haskell.TH doesn't reexport everything from Language.Haskell.TH.Lib -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: RyanGlScott Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Template | Version: 8.0.1 Haskell | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The documentation for `Language.Haskell.TH.Lib` [http://git.haskell.org/ghc.git/blob/9e862765ffe161da8a4fd9cd67b0a600874feaa… /template-haskell/Language/Haskell/TH/Lib.hs#l8 claims]: {{{#!hs -- All of the exports from this module should -- be "public" functions. The main module TH -- re-exports them all. }}} Sadly, this isn't true. There are a number of functions that `Language.Haskell.TH` accidentally forgets to export. Notably, this includes all of the unboxed tuple library functions, as noticed [https://phabricator.haskell.org/D2448#inline-20282 here], but there are many others as well. To avoid this sort of thing in the future, I think the cleanest solution would be to just reexport the entirely of the `Language.Haskell.TH.Lib` module from `Language.Haskell.TH`. This would have the downside that you'll have to click an extra link in order to see the Haddocks for `Language.Haskell.TH.Lib`, but I believe the simplification will be worth it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12992> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #7325: threadDelay mistreats minBound and maxBound in some configurations
by GHC 18 Dec '16

18 Dec '16

#7325: threadDelay mistreats minBound and maxBound in some configurations -------------------------------------+------------------------------------- Reporter: joeyadams | Owner: Type: bug | Status: closed Priority: high | Milestone: 8.2.1 Component: Runtime System | Version: 7.6.1 Resolution: fixed | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: Incorrect result | Test Case: at runtime | base/tests/T8089 Blocked By: | Blocking: Related Tickets: #9722 | Differential Rev(s): Phab:D2861 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7325#comment:15> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7325: threadDelay mistreats minBound and maxBound in some configurations
by GHC 18 Dec '16

18 Dec '16

#7325: threadDelay mistreats minBound and maxBound in some configurations -------------------------------------+------------------------------------- Reporter: joeyadams | Owner: Type: bug | Status: patch Priority: high | Milestone: 8.2.1 Component: Runtime System | Version: 7.6.1 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: Incorrect result | Test Case: at runtime | base/tests/T8089 Blocked By: | Blocking: Related Tickets: #9722 | Differential Rev(s): Phab:D2861 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari <ben@…>): In [changeset:"2d1beb1ec84c2d22c6be83944ef4ea8626abd76a/ghc" 2d1beb1e/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="2d1beb1ec84c2d22c6be83944ef4ea8626abd76a" rts/win32/IOManager: Fix integer types This code has been broken on 64-bit systems for some time: the length and timeout arguments of `addIORequest` and `addDelayRequest`, respectively, were declared as `int`. However, they were passed Haskell integers from their respective primops. Integer overflow and madness ensued. This resulted in #7325 and who knows what else. Also, there were a few left-over `BOOL`s in here which were not passed to Windows system calls; these were changed to C99 `bool`s. However, there is still a bit of signedness inconsistency within the `delay#` call-chain, * `GHC.Conc.IO.threadDelay` and the `delay#` primop accept `Int` arguments * The `delay#` implementation in `PrimOps.cmm` expects the timeout as a `W_` * `AsyncIO.c:addDelayRequest` expects an `HsInt` (was `int` prior to this patch) * `IOManager.c:AddDelayRequest` expects an `HsInt`` (was `int`) * The Windows `Sleep` function expects a `DWORD` (which is unsigned) Test Plan: Validate on Windows Reviewers: erikd, austin, simonmar, Phyx Reviewed By: Phyx Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2861 GHC Trac Issues: #7325 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7325#comment:14> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5654: Profiling semantics bug
by GHC 18 Dec '16

18 Dec '16

#5654: Profiling semantics bug -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: low | Milestone: 8.2.1 Component: Profiling | Version: 7.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | profiling/should_run/scc004 Blocked By: | Blocking: Related Tickets: #10007 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari <ben@…>): In [changeset:"2a02040b2e23daa4f791afc290c33c9bbe3c620c/ghc" 2a02040b/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="2a02040b2e23daa4f791afc290c33c9bbe3c620c" Fix bug in previous fix for #5654 I forgot to account for BCOs, which have a different layout from functions. This caused crashes when using profiling with GHCi (via -fexternal-interpreter -prof), which unfortunately is not tested at all by validate, even when profiling is enabled. I'm going to add some testing that would have caught this in a separate patch. Test Plan: ``` cd nofib/spectral/puzzle && make NoFibWithGHCi=YES EXTRA_RUNTEST_OPTS='-fexternal-interpreter -prof' ``` New testsuite tests coming in a separate diff. Reviewers: niteria, austin, erikd, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2868 GHC Trac Issues: #5654 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5654#comment:19> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5654: Profiling semantics bug
by GHC 18 Dec '16

18 Dec '16

#5654: Profiling semantics bug -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: low | Milestone: 8.2.1 Component: Profiling | Version: 7.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | profiling/should_run/scc004 Blocked By: | Blocking: Related Tickets: #10007 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari <ben@…>): In [changeset:"90cfa84981ee1f9fb756a3af1bd707674c18c034/ghc" 90cfa849/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="90cfa84981ee1f9fb756a3af1bd707674c18c034" Run some tests with -fexternal-interpreter -prof We don't have any other tests for this, except one Template Haskell test. This would have caught the bug I just fixed in D2868, at least when validating with profiling on. Test Plan: Ran tests Reviewers: niteria, austin, erikd, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2869 GHC Trac Issues: #5654 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5654#comment:20> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #3384: Add HsSyn prettyprinter tests
by GHC 17 Dec '16

17 Dec '16

#3384: Add HsSyn prettyprinter tests -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: task | Status: closed Priority: normal | Milestone: 8.2.1 Component: Test Suite | Version: Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2752 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Tamar Christina <tamar@…>): In [changeset:"d88efb7048160c3031eadb4f3b729e9fe406414d/ghc" d88efb7/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="d88efb7048160c3031eadb4f3b729e9fe406414d" Fix Pretty printer tests on Windows Summary: D2752 added some tests which escapes string literals. This means newlines are converted before they get normalized by the IO functions. So on Windows \r\n would be in the output while \n was expected. Test Plan: make test -C testsuite/tests/printer Reviewers: austin, bgamari, alanz Reviewed By: alanz Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2873 GHC Trac Issues: #3384 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3384#comment:19> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10723: Make declarations in signatures "weakly bound" until they are used
by GHC 17 Dec '16

17 Dec '16

#10723: Make declarations in signatures "weakly bound" until they are used -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature | Status: new request | Priority: normal | Milestone: Component: Package | Version: 7.11 system | Keywords: backpack | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Suppose you are the author of a library in a Backpack world, and you publish a signature package which defines the entire public facing interface of your library. The library `foo` which uses of your library decides to `include` the signature package for convenience, but actually only uses a small portion of the API. Later, you make a BC-breaking change in one part of the library and release a new signature package. The library `bar` which uses your library includes this NEW signature package, using a different portion of the API which was unaffected by the by the BC change. Now, a hapless user tries to use `foo` and `bar`, but Backpack complains that the requirements are not compatible. What's the problem here? The practice of writing reusable signature packages for people to use caused the requirements of `foo` and `bar` to become too large, since they included a lot of junk that these libraries didn't actually use. It would be far better if you could `include` a signature package, but only "require" the bits of it that you actually used! How can we achieve this? 1. We augment the `ModIface` of signature merges (#10690) to record whether or not a declaration was (transitively) used or not by some module. Used declarations must be filled, but unused ones are treated more flexibly: if they are merged with a different, incompatible but used requirement, they disappear, and we don't check if an implementing module actually implemented the declaration. (If two unused incompatible requirements are merged, we just erase the name.) 2. How do we compute the usage info? I think it will have to be done during shaping (which runs the renamer). We only need to annotate each declaration a signature with the transitive set of names from other signatures that it has used--this can be incrementally computed. (It's not necessary to annotate declarations in modules, since they are always assumed to use holes). Then whenever a declaration from a signature is used in a module, we mark its transitive set as used. This information can then be used later when constructing the merged `ModIface` which represents the "public requirement" of the package. So, for example, a package containing only signatures would contain all unused declarations (however, they may start being used by a package which includes them). Any unused declaration which isn't mixed with another incompatible declaration can be imported (causing it to be used), but we will complain if you try to use a name and we can't tell which declaration to use. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10723> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

Re: [GHC] #11445: Turn on SplitSections by default
by GHC 17 Dec '16

17 Dec '16

#11445: Turn on SplitSections by default -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Build System | Version: 8.0.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 11285 Related Tickets: | Differential Rev(s): Phab:D1800 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari <ben@…>): In [changeset:"8f71d9581ee0a1826c0105e51a7048f0c7669492/ghc" 8f71d958/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="8f71d9581ee0a1826c0105e51a7048f0c7669492" Enable split sections by default where possible On non-windows platforms with GNU ld, enable SplitSections in the GHC build by default. Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: DemiMarie, thomie Differential Revision: https://phabricator.haskell.org/D1800 GHC Trac Issues: #11445 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11445#comment:21> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0