March 2019 - ghc-devs

New and improved ghc-in-ghci target
by Matthew Pickering 12 Mar '19

12 Mar '19

Hi all, My patch to improve the ghc-in-ghci target just got merged a few minutes ago. Now from a clean tree it only takes a few minutes to launch the target. You can now load ghc into ghci by running the following script: ./hadrian/ghci.sh https://gitlab.haskell.org/ghc/ghc/tree/master/hadrian#fast-feedback-using-… Please try it out and open tickets if there are any issues on your system. Matt

2 1

Trac to GitLab migration underway
by Ben Gamari 12 Mar '19

12 Mar '19

Hello everyone, I have started the process of migrating GHC's Trac content to GitLab. GitLab (gitlab.haskell.org) and Trac (ghc.haskell.org) will be down until this process has finished. I will post updates as necessary. However, if you do need to refer to a ticket, you are welcome to use the staging server [1], which has a reasonably up-to-date (read-only) snapshot of our Trac tickets. However, do note that unfortunately authentication via GitHub will not work on this site. Cheers, - Ben [1] https://gitlab.staging.haskell.org/

10 18

git clone https://gitlab.haskell.org/ghc/ghc.git on travis doesn't work
by Shayne Fletcher 10 Mar '19

10 Mar '19

I appreciate this isn't really "our" problem :) Nonetheless, if there's any config we can do on the repo on gitlab, that would be cool. Other URLs (like github) for example are fine - something specific to gitlab. -- This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.digitalasset.com/emaildisclaimer.html <http://www.digitalasset.com/emaildisclaimer.html>. If you are not the intended recipient, please delete this message.

5 11

Why can't we re-install the template-haskell package?
by Moritz Angermann 08 Mar '19

08 Mar '19

Dear friends, as I'm working on making lib:ghc re-installable [1][2]. Ideally I'd prefer we only had to freeze rts + ghc-prim and maybe base (which would implicate the integer library). However, we apparently can't re-install Template Haskell I'm told. Not just not upgrade it, but not even re-install it (same version). I've attached some rough dependency graph (which I hope is correct for ghc 8.8). Fixing template-haskell implies ghc-boot-th, pretty, deepseq and array. Can someone shed some light onto the details here? What are the fundamental issues we can't reinstall template-haskell? Cheers, Moritz -- [1]: https://gitlab.haskell.org/ghc/ghc/merge_requests/490 [2]: https://gitlab.haskell.org/ghc/ghc/merge_requests/506

4 4

git.haskell.org is broken
by Shayne Fletcher 08 Mar '19

08 Mar '19

As of today, git clone git://git.haskell.org/ghc.git --recursive is failing with, error: Server does not allow request for unadvertised object 94855814e2e4f7a0f191ffa5b4c98ee0147e3174 Fetched in submodule path 'libraries/binary', but it did not contain 94855814e2e4f7a0f191ffa5b4c98ee0147e3174. Direct fetching of that commit failed. -- Shayne Fletcher Language Engineer c: +1 917 699 7763 e: shayne.fletcher(a)daml.com Digital Asset Holdings, LLC 4 World Trade Center 150 Greenwich Street, 47th Floor <https://maps.google.com/?q=150+Greenwich+Street,+47th+Floor%C2%A0+%C2%A0+%C…> New York, NY 10007, USA <https://maps.google.com/?q=150+Greenwich+Street,+47th+Floor%C2%A0+%C2%A0+%C…> digitalasset.com <http://www.digitalasset.com/> -- This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.digitalasset.com/emaildisclaimer.html <http://www.digitalasset.com/emaildisclaimer.html>. If you are not the intended recipient, please delete this message.

3 3

Re: Why can't we re-install the template-haskell package?
by Ryan Scott 07 Mar '19

07 Mar '19

My (limited) understanding is that template-haskell is not reinstallable for the same reasons that base and ghc-prim aren't reinstallable: the GHC codebase directly wires in several definitions several functions, types, and data constructors from template-haskell. See THNames [1]. If one were to, say, use GHC 8.6 but install a different version of template-haskell than the one that came bundled with 8.6, then it's almost certain that lots of code in THNames would no longer work, since they could be referencing identifiers that no longer exist (if the new version of template-haskell doesn't have them). Ryan S. ----- [1] https://gitlab.haskell.org/ghc/ghc/blob/25c3dd39f7d446f66b5c967be81f80cd7fa…

1 0

Final steps in GHC's Trac-to-GitLab migration
by Ben Gamari 06 Mar '19

06 Mar '19

Hi everyone, Over the past few weeks we have been hard at work sorting out the last batch of issues in GHC's Trac-to-GitLab import [1]. At this point I believe we have sorted out the issues which are necessary to perform the final migration: * We are missing only two tickets (#1436 and #2074 which will require a bit of manual intervention to import due to extremely large description lengths) * A variety of markup issues have been resolved * More metadata is now preserved via labels. We may choose to reorganize or eliminate some of these labels in time but it's easier to remove metadata after import than it is to reintroduce it. The logic which maps Trac metadata to GitLab labels can be found here [2] * We now generate a Wiki table of contents [3] which is significantly more readable than GitLab's default page list. This will be updated by a cron job until underlying GitLab pages list becomes more readable. * We now generate redirects for Trac ticket and Wiki links (although this isn't visible in the staging instance) * Milestones are now properly closed when closed in Trac * Mapping between Trac and GitLab usernames is now a bit more robust As in previous test imports, we would appreciate it if you could have a look over the import and let us know of any problems your encounter. If no serious issues are identified with the staging site we plan to proceed with the migration this coming weekend. The current migration plan is to perform the final import on gitlab.haskell.org on Saturday, 9 March 2019. This will involve both gitlab.haskell.org and ghc.haskell.org being down for likely the entirety of the day Saturday and likely some of Sunday (EST time zone). Read-only access will be available to gitlab.staging.haskell.org for ticket lookup while the import is underway. After the import we will wait at least a week or so before we begin the process of decommissioning Trac, which will be kept in read-only mode for the duration. Do let me know if the 9 March timing is problematic. Cheers, - Ben [1] https://gitlab.staging.haskell.org/ghc/ghc [2] https://github.com/bgamari/trac-to-remarkup/blob/master/TicketImport.hs#L227 [3] https://gitlab.staging.haskell.org/ghc/ghc/wikis/index

7 15

[ANNOUNCE] GHC 8.6.4 is now available
by Ben Gamari 06 Mar '19

06 Mar '19

Hello everyone, The GHC team is very happy to announce the availability of GHC 8.6.4, a bugfix release in the GHC 8.6 series. The source distribution, binary distributions, and documentation for this release are available at https://downloads.haskell.org/~ghc/8.6.4 The 8.6.4 release fixes several regressions present in 8.6.3 including: - A regression resulting in segmentation faults on Windows introduced by the fix for #16071 backported in 8.6.3. This fix has been reverted, meaning that 8.6.4 is once again susceptible to #16071. #16071 will be fixed in GHC 8.8.1. - A bug resulting in incorrect locking on Darwin, potentially resulting in hangs at shutdown (#16150) - A few bugs in the profiled runtime resulting in the potential for memory unsafety has been fixed (#15508). - The `process` and `transformers` libraries shipped now properly reflect released Hackage releases (#16199) - A bug where TH name resolution would break in a plugin context has been fixed (#16104) - Compilers that do not support TemplateHaskell no longer advertise such support in `--supported-languages` (#16331) As a few of these issues are rather serious users are strongly encouraged to upgrade. See Trac [1] for a full list of issues resolved in this release. Note that this release ships with one significant but long-standing bug (#14251): Calls to functions taking both Float# and Double# may result in incorrect code generation when compiled using the LLVM code generator. This is not a new issue, it has existed as long as the LLVM code generator has existed; however, changes in code generation in 8.6 made it more likely that user code using only lifted types will trigger it. Note also that this is the first release cut from our (yet again) revamped continuous integration infrastructure. While we have done a great deal of checking to ensure that the build configuration reflects that of previous releases, do let us know if something looks off. Happy compiling! Cheers, - Ben [1] https://ghc.haskell.org/trac/ghc/query?status=closed&milestone=8.6.4&col=id…

7 14

RE: [GHC] #16348: GHC HEAD regression: tyConAppArgs
by Simon Peyton Jones 06 Mar '19

06 Mar '19

Matthew, Ben I've just received 40-odd messages like this one. It looks as if Marge is now sending commit messages at Trac ticket messages, which is great. Will that happen after the move to GitLab. Also, is this sudden wave because a whole lot of commits have now landed in master? Or is it somehow an old backlog stuck in a mail queue? There may be some housekeeping to do, to close tickets, check regression tests and add pointers to the appropriate tests. Is anyone up for doing that? Thanks Simon | -----Original Message----- | From: ghc-tickets <ghc-tickets-bounces(a)haskell.org> On Behalf Of GHC | Sent: 04 March 2019 18:51 | Subject: Re: [GHC] #16348: GHC HEAD regression: tyConAppArgs | | #16348: GHC HEAD regression: tyConAppArgs | -------------------------------------+------------------------------------- | Reporter: RyanGlScott | Owner: (none) | Type: bug | Status: closed | Priority: highest | Milestone: 8.10.1 | Component: Compiler | Version: 8.7 | Resolution: fixed | Keywords: | Operating System: Unknown/Multiple | Architecture: | | Unknown/Multiple | Type of failure: Compile-time | Test Case: | crash or panic | simplCore/should_compile/T16348 | Blocked By: | Blocking: | Related Tickets: | Differential Rev(s): | Wiki Page: | | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.ha | skell.org%2Fghc%2Fghc%2Fmerge_requests%2F416&data=02%7C01%7Csimonpj%40m | icrosoft.com%7C50e6bec9985e4121351808d6a0d2a90f%7C72f988bf86f141af91ab2d7cd | 011db47%7C1%7C0%7C636873224010230414&sdata=SvX8wLsObYmasJTvB6yT9CQbxoFK | ZkdGpv7ZHfDRqYs%3D&reserved=0 | -------------------------------------+------------------------------------- | | Comment (by Matthew Pickering <matthewtpickering@…>): | | In [changeset:"c25b135ff5b9c69a90df0ccf51b04952c2dc6ee1/ghc" | c25b135f/ghc]: | {{{ | #!CommitTicketReference repository="ghc" | revision="c25b135ff5b9c69a90df0ccf51b04952c2dc6ee1" | Fix exprIsConApp_maybe | | In this commit | commit 7833cf407d1f608bebb1d38bb99d3035d8d735e6 | Date: Thu Jan 24 17:58:50 2019 +0100 | Look through newtype wrappers (Trac #16254) | | we made exprIsConApp_maybe quite a bit cleverer. But I had not paid | enough attention to keeping exactly the correct substitution and | in-scope set, which led to Trac #16348. | | There were several buglets (like applying the substitution twice in | exprIsConApp_maybe, but the proximate source of the bug was that we were | calling addNewInScopeIds, which deleted things from the substitution as | well as adding them to the in-scope set. That's usually right, but not | here! | | This was quite tricky to track down. But it is nicer now. | }}} | | -- | Ticket URL: | <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.haske | ll.org%2Ftrac%2Fghc%2Fticket%2F16348%23comment%3A7&data=02%7C01%7Csimon | pj%40microsoft.com%7C50e6bec9985e4121351808d6a0d2a90f%7C72f988bf86f141af91a | b2d7cd011db47%7C1%7C0%7C636873224010230414&sdata=Hmm1p52EqBpdLX1sFkutPm | Z8hSjY%2FtzS1FZqlFYCxYI%3D&reserved=0> | GHC | <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.haske | ll.org%2Fghc%2F&data=02%7C01%7Csimonpj%40microsoft.com%7C50e6bec9985e41 | 21351808d6a0d2a90f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63687322401 | 0230414&sdata=AuTz%2BM22brpeoXARiWrhvqlGd4w2myu1YNobnhj16L8%3D&rese | rved=0> | The Glasgow Haskell Compiler

3 5

Haddock tree spongled
by Simon Peyton Jones 06 Mar '19

06 Mar '19

Devs In a clean, up-to-date master I try to say Bash$ git submodule update fatal: reference is not a tree: 07f2ca98fd4249dc6ebad053bd6aef90c814efe0 Unable to checkout '07f2ca98fd4249dc6ebad053bd6aef90c814efe0' in submodule path 'utils/haddock' What should I do? Thanks Simon

2 2