- ghc-devs - Haskell.org

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

Testing GHC against Hackage via CI
by Ben Gamari 05 Mar '19

05 Mar '19

Hello everyone, As many of you know, recently I have been working on bringing up infrastructure for using CI-produced binary distributions to build a subset of Hackage using the head.hackage patchset. Happily, this effort has now converged on a usable result, embodied in two merge requests: * https://gitlab.haskell.org/ghc/head.hackage/merge_requests/2 * https://gitlab.haskell.org/ghc/ghc/merge_requests/465 ghc/head.hackage!2 adds CI support to head.hackage. In addition to the usual pass/fail status, this job produces (e.g. [1]) a few additional products: * a JSON summary of the run, describing the dependency graph and pass/fail state of each package. we can feed to an external service to track newly-failing packages. * a (rendered) graphviz graph showing the dependency structure of the built packages, each node colored by its pass/fail state * a tarball of build logs, each including statistics from -ddump-timings. The hope here is that we can use this to track compiler performance on real-world code ghc/ghc!465 adds a job to GHC's own CI pipeline to trigger a head.hackage job using the binary distribution produced earlier in the pipeline. This job will run automatically under a variety of circumstances: * via the scheduled nightly pipeline * on merge requests labelled with the `user-facing` label * when manually started using a button on the MR's Pipelines tab Currently the head.hackage MR tests only a small number of Hackage packages (and their dependencies). Specifically, we currently build `aeson`, `criterion`, `singletons`, `servant`, and `scotty`. This pulls in 127 packages in total. There are a few things that remain to be done: * Better document the existence of the job and how it is triggered * Document how to update the list of tested packages * Work out how to handle tracking of persistent breakage (e.g. we want a notification when a package initially breaks but not in later builds) * Automatically push patched packages to a Hackage repository (e.g. head.hackage.org) as a result of CI. Cheers, - Ben [1] https://gitlab.haskell.org/ghc/head.hackage/-/jobs/38022

2 2

Re: Testing GHC against Hackage via CI
by Ryan Scott 05 Mar '19

05 Mar '19

This is fantastic work! I'm looking forward to using this. Are there plans to merge GitLab's fork of head.hackage back into the upstream repo [1]? I ask since I regularly submit patches to upstream, but if the GitLab CI is using the fork, then it may take some time for upstream changes to make their way back to the fork. Ryan S. ----- [1] https://github.com/hvr/head.hackage

2 1

__mingw_vsnw_printf definition
by Ben Gamari 05 Mar '19

05 Mar '19

Hi Tamar, Recently I've been working on (finally) stabilizing our remaining CI configurations (namely i386/Linux and Windows). I've opened a number of tickets (see the list in !487 [1]) but one of these in particular I'd like your input on. Specifically #16387: The problem is the apparent multiple-definition of __mingw_vsnwprintf: once in mingwex.a and again in RtsSymbols. Unfortunately I have been unable to reproduce this error locally, so debugging has been a bit tricky. The RtsSymbols entry was introduced in 4de585a5c1ac3edc2914cebcac1753b514051a89 (which lifted the MAX_PATH restriction in the RTS) but there was no explanation for why. Do you happen to recall why you added it? Note [Symbols for MinGW's printf] seems relevant, but seems to only discuss the entries for _lock_file and _unlock_file. Cheers, - Ben [1] https://gitlab.haskell.org/ghc/ghc/merge_requests/487

1 0

gitlab migration
by Richard Eisenberg 02 Mar '19

02 Mar '19

Hi all, As I'm wrapping up some ICFP papers, I realize that I sometimes link to Trac tickets in published papers. It would be a shame for all these links to suddenly go dead, and I'm sure that my papers aren't the only places external sites link to Trac. Is it expected that, after the full migration, the Trac URLs will redirect? Thanks, Richard

2 1