- ghc-devs - Haskell.org

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

Gitlab bug?
by Simon Peyton Jones 26 Feb '19

26 Feb '19

Look here: https://gitlab.haskell.org/ghc/ghc/merge_requests/444/diffs#350c4076427c611… Look at the comment "Is this zipping necessary? We haven't zonked the scoped_kvs or the tc_tvs, I think" from Richard Eisenberg, just below line 1925 in TcHsType. Now click on the grey "..." above his comment, to expand more code lines above. Uh oh! * The same comment now occurs twice, just below line 1904, and again just below 1925. * The first time it's on the wrong line of code * But in the second position (the correct one) the "Reply" box is inactive. I can't type into it. Is this is a bug? How to report it? Simon

3 5

RE: --share option for hadrian doesn't work with hs-boot files
by Andrey Mokhov 22 Feb '19

22 Feb '19

Hi Matt, Thanks! Switching branches that add/remove hs-boot files is exactly the kind of scenario which is hard to predict :) This looks like a bug, so please create a ticket. If you manage to reproduce this somehow without switching branches, e.g. by just adding or removing an hs-boot file, that would make it easier to debug. > Could you please write down some advice Andrey about > how to solve issues like this? It seems very fragile making > sure that every case is covered. Shake 0.17.6 has the following two commands that may help to partially clean up the cache in presence of such bugs: --share-list List the shared cache files. --share-remove[=SUBSTRING] Remove the shared cache keys. By running Hadrian with --share-remove=_build/stage0/compiler/build/Var* you should be able to evict the corresponding build rules from the cache and hopefully the build will go through. If this does help, please also mention this in the ticket. Cheers, Andrey From: Matthew Pickering [mailto:matthewtpickering@gmail.com] Sent: 22 February 2019 08:53 To: GHC developers <ghc-devs(a)haskell.org>; Andrey Mokhov <andrey.mokhov(a)newcastle.ac.uk> Subject: --share option for hadrian doesn't work with hs-boot files I have been trying the new `--share` option implemented in hadrian but I haven't actually managed to complete any builds yet with it enabled after the initial one. The current error is ``` <no location info>: error: ‘Var.AnonArgFlag’ is exported by the hs-boot file, but not exported by the module Error when running Shake build system: at action, called at src/Rules.hs:35:19 in main:Rules at need, called at src/Rules.hs:52:5 in main:Rules * Depends on: _build/stage0/bin/ghc at need, called at src/Utilities.hs:71:18 in main:Utilities * Depends on: _build/stage0/compiler/build/libHSghc-8.9.a at need, called at src/Rules/Library.hs:118:5 in main:Rules.Library * Depends on: _build/stage0/compiler/build/Var.o * Raised the exception: user error (Development.Shake.cmd, system command failed ``` I get this after building Simon's `FunTy` patch which does add this flag and the definition to `Var.hs-boot` and then switching back to master with the cache enabled. Could you please write down some advice Andrey about how to solve issues like this? It seems very fragile making sure that every case is covered. Cheers, Matt

1 0

--share option for hadrian doesn't work with hs-boot files
by Matthew Pickering 22 Feb '19

22 Feb '19

I have been trying the new `--share` option implemented in hadrian but I haven't actually managed to complete any builds yet with it enabled after the initial one. The current error is ``` <no location info>: error: ‘Var.AnonArgFlag’ is exported by the hs-boot file, but not exported by the module Error when running Shake build system: at action, called at src/Rules.hs:35:19 in main:Rules at need, called at src/Rules.hs:52:5 in main:Rules * Depends on: _build/stage0/bin/ghc at need, called at src/Utilities.hs:71:18 in main:Utilities * Depends on: _build/stage0/compiler/build/libHSghc-8.9.a at need, called at src/Rules/Library.hs:118:5 in main:Rules.Library * Depends on: _build/stage0/compiler/build/Var.o * Raised the exception: user error (Development.Shake.cmd, system command failed ``` I get this after building Simon's `FunTy` patch which does add this flag and the definition to `Var.hs-boot` and then switching back to master with the cache enabled. Could you please write down some advice Andrey about how to solve issues like this? It seems very fragile making sure that every case is covered. Cheers, Matt

1 0

spj-wibbles
by Simon Peyton Jones 21 Feb '19

21 Feb '19

Matthew, Ben, David I've just submitted MR 426. It's a batch of four patches<https://gitlab.haskell.org/ghc/ghc/merge_requests/426/commits>, one of which makes the GHC tree validate again. Might you keep an eye on it. David/anyone: one of them "Stop inferring polymorphic kinds" makes a small change to HsSyn (removing a field). I don't know whether that'll require changing Haddock - or how to do so. Might you check? Gotta run Thanks! Simon

1 0