- ghc-devs - Haskell.org

Commit searching
by chessai . 12 May '19

12 May '19

Devs, Is there a way to take the sha1 of a git commit and find which released version of GHC contains that commit, without resorting to a manual cross-reference? Is it possible there could be some sort of webpage where this information could be made accessible, just by pasting in a commit?

3 3

CI on forked projects: Darwin woes
by Kevin Buhr 12 May '19

12 May '19

Over the past few days, I've submitted several merge requests from branches on my forked project (mostly because I didn't even realize pushing to a branch on the main project was an alternative). When those MRs run under CI, I've had a bunch of failures due to timeouts waiting on a darwin-x86_64 runner. I was a little mystified that no other pipelines besides mine seemed to be having this problem, but I've come to understand that MRs submitted from branches on the main project use a different, larger set of runners than the shared runners used by MRs from branches on forked projects. Under my project, I can view the available shared runners under the "Settings" -> "CI/CD" -> "Runners" tab, and the problem seems to be that there's only one darwin runner ("b4bc6410" / mac-mini-x86_64-darwin-davxkc). This machine is a trooper, but it unfortunately shares a circuit breaker with a toaster oven, so it goes offline every time someone wants a bagel, and the rest of the time it must be running CI for a few hundred GHC forks. I ended up deleting an (unreviewed) MR sourced from my branch, and pushing it to the main project and resubmitting just to get the CI to run. (Admittedly, it failed, but at least not on darwin!) I obviously don't want to do this with the merge requests that have already been reviewed. Is this a temporary problem? Is there anything I can do other than keep retrying the darwin jobs every couple days? Also, is there a better place than "ghc-dev" to send these sorts of GitLab/CI issues? I thought there might be a project dedicated to it, but if so I couldn't find it. -- Kevin Buhr <buhr(a)asaurus.net>

3 2

Website for viewing proposals
by Matthew Pickering 10 May '19

10 May '19

Hi, It would be useful if there was a canonical way to link and view GHC proposals rather than relying on github's RST viewer. Can we set up a website, `ghc.haskell.org/proposals`, which is deployed to automatically when a new accepted proposal is merged? FWIW, if the proposals process was also on gitlab then doing this deployment would be easy using our CI infrastructure but I don't know how to set up something similar on github. Cheers, Matt

5 14

Question about Gitlab MR workflow.
by Iavor Diatchki 10 May '19

10 May '19

Hello, I've just had a go at making a small MR on our new Gitlab system, and I am a bit confused about the intended workflow. I was following these instructions : https://gitlab.haskell.org/ghc/ghc/wikis/working-conventions/fixing-bugs My question is about the steps after 2 (i.e., 3 and 4). Step 5 about the beer I already did :-) Here was my experience so far: 1. I made the changes I wanted yesterday over lunch: the change was quite trivial, I added a NOINLINE pragma and some comments and I mage the MR. 2. Sometime in the evening (half a day later!) I got an e-mail from the CI system that something had failed. It was quite hard to tell what had failed, and after poking around at the logs, it seemed like it was some sort of spurious failures because things had timed out, I think? 3. Today I got some feedback from a reviewer about some changes I should make to the MR. As I was working on those, I noticed that every time I push to the MR, the CI is forking a new job. I cancelled some of those manually, to save on resources, as they already seem to be taking half a day. 4. After making the changes, I noticed that Gitlab is asking me to rebase my changes because, presumably, some other things have already been merged. It is easy enough to rebase my MR, but every time I do so, this fires up a new CI job. And, of course, this is going to keep happening, until I am lucky enough to rebase just at the right time? This doesn't seem right. So my questions are specifically about step 3 and 4: About 3: wouldn't it make more sense to start firing up CI jobs only after an MR has been approved for merging? About 4: I really don't understand how this rebasing business is intended to work: every time I rebase, I new CI job is fired up. But, presumably, while this is going, other things are going to be merged with `master`, so I'd need to rebase again. So, when would I ever stop rebasing? Furthermore, in my case the rebase is trivial, but with a larger patch, doing multiple rebases seems like a lot of wasted work. Any help would be appreciated! -Iavor

7 8

Old build system broken
by Simon Peyton Jones 09 May '19

09 May '19

I know we are supposed to be using Hadrian now, but is the old build system supposed to be broken? A clean build fails with "inplace/bin/ghc-cabal" check libraries/ghc-prim "inplace/bin/ghc-cabal" configure libraries/ghc-prim dist-install --with-ghc="/home/simonpj/code/HEAD/inplace/bin/ghc-stage1" --with-ghc-pkg="/home/simonpj/code/HEAD/inplace/bin/ghc-pkg" --disable-library-for-ghci --enable-library-vanilla --enable-library-for-ghci --disable-library-profiling --enable-shared --configure-option=CFLAGS="-Wall -Werror=unused-but-set-variable -Wno-error=inline" --configure-option=LDFLAGS=" " --configure-option=CPPFLAGS=" " --gcc-options="-Wall -Werror=unused-but-set-variable -Wno-error=inline " --with-gcc="gcc" --with-ld="ld.gold" --with-ar="ar" --with-alex="/usr/bin/alex" --with-happy="/usr/bin/happy" Configuring ghc-prim-0.6.1... ghc-cabal: '/home/simonpj/code/HEAD/inplace/bin/ghc-stage1' exited with an error: Failed to read "target arch" value "" libraries/ghc-prim/ghc.mk:4: recipe for target 'libraries/ghc-prim/dist-install/package-data.mk' failed make[1]: *** [libraries/ghc-prim/dist-install/package-data.mk] Error 1 Makefile:123: recipe for target 'all' failed make: *** [all] Error 2 simonpj@MSRC-3645512:~/code/HEAD$

6 7

Is cleaning up old issues worthwhile?
by Kevin Buhr 08 May '19

08 May '19

I presume I can't be the first to ask this question, but I tried searching the ghc-devs archives and didn't find anything. After accidentally clicking on the sort order button in the GitLab issue list, I found myself browsing 18-year-old open issues that are clearly obsolete (e.g., #515 related to bad source location info in LHS files long since fixed, #517 which looks like a transient issue with error messages affecting HEAD in March 2001, #519 which refers to "ghc -M" reading "import" statements from comments which I tried and failed to duplicate. etc.). I would be interested in going through some of these and triaging and closing them where appropriate. But I also don't want to be "that guy" -- you know, the person who systematically works his or her way through the wiki boldfacing all occurrences of the word "GHC" or submits 1200 merge requests to remove doubled-space-after-period occurrences in comments. So, the first question is, would working on cleaning up these issues be useful, or would it generate too much noise to be worthwhile? Second, if it *is* useful, what sort of policy/procedure would be most helpful? There are a bunch of these issues that: * have gone many years without any non-administrative activity * have clear test cases that can't be duplicated with modern GHC * don't involve any apparent unresolved technical issues I'd be pretty comfortable adding a comment documenting my failure to duplicate them and then closing them. So, that might be a good first pass. Is there any reason *not* to simply comment and close them immediately? For example, I already closed #497 and #515 on this basis. Would it be better to comment on them, maybe tag them with a new label like "issue cleanup", and have a grace period before closing them? -- Kevin Buhr <buhr(a)asaurus.net>

6 10

MR titles
by Simon Peyton Jones 08 May '19

08 May '19

Friends In this MR<https://gitlab.haskell.org/ghc/ghc/merge_requests/908>, Vlad includes the number of the ticket it fixes in the title of the MR. That is so helpful: * It links the MR back to the issue * And does so in large font (screen shot below) * And the link is clickable, even in the title. I suggest we document this in our GHC-best-practice guide, and get everyone to do it. Would you agree Simon [cid:image001.jpg@01D50583.988DEB70]

3 3

Keeping track of issues
by Simon Peyton Jones 08 May '19

08 May '19

Ben I'm struggling to establish a clear understanding of the life cycle of an issue. Consider https://gitlab.haskell.org/ghc/ghc/issues/15872. Here is my faithfully recorded chain of thought at 2330 on a Tuesday night. * I can see that it is closed * But I wonder if it was fixed? * Well, scrolling up from the bottom, apparently it was mentioned in no fewer than six patches. That's odd. Why is this issue mentioned in six patches? * Oh, one of those six patches is a dup, mentioned twice. No idea why. * Are any of the five The Patch that is designed to fix this issue. Indeed does The Patch exist at all? And what MR is it in? * Oh, what is that MR? * Hmm. Well Ryan says "I've opened MR 851". Maybe that's it? * Let's head over to MR 851: https://gitlab.haskell.org/ghc/ghc/merge_requests/851 * Oh! It just says "Closed". I was hoping it'd say "merged", but no. * Uh oh. Near the top it says "Closed by Omer"... "the changes were not merged into master". * Then scrolling further down there is a lot of noise from Marge, followed by a presumably hand-written message from Omer saying "Merged as cc495d57</ghc/ghc/commit/cc495d5777c01ef62129df15caacf87b0e430c6b>.". * Huh. So maybe it did get merged after all. You can see how confused I am. It all just feels like much more work to find relevant info than it should be. It's frustrating because all the info is in the system, -- it's just hard (for me) to find. An issue should say prominently: this is The MR (or MRs) that fixes the issue. It should be easy to tell if those MR(s) have been successfully merged - along with their commit messages (this will come Moe Bot). Trac used to let you close a ticket as "fixed" or "wont-fix" or "invalid" etc. This was Jolly Useful. Doesn't Gitlab? Similarly, MRs sould be closed as "merged" or "abandoned". Much of this is not under your control - it's what GitLab does. But maybe we should have stronger best-practice guidelines. Eg "Never just close an issue; always say "Closing as won't fix" or...". etc. Simon

2 1

[ANNOUNCE] GHC 8.8.1-alpha1 is now available
by Ben Gamari 08 May '19

08 May '19

Hello everyone, The GHC team is pleased to announce the first alpha release of GHC 8.8.1. The source distribution, binary distributions, and documentation are available at https://downloads.haskell.org/~ghc/8.8.1-alpha1 A draft of the release notes is also available [1]. This release is the culmination of over 3000 commits by over one hundred contributors and has several new features and numerous bug fixes relative to GHC 8.6: * Profiling now works correctly on 64-bit Windows (although still may be problematic on 32-bit Windows due to platform limitations; see #15934) * A new code layout algorithm for amd64's native code generator * The introduction of a late lambda-lifting pass which may reduce allocations significantly for some programs. * Further work on Trees That Grow, enabling improved code re-use of the Haskell AST in tooling * More locations where users can write `forall` (GHC Proposal #0007) * Further work on the Hadrian build system This release starts the pre-release cycle for GHC 8.8. This cycle is starting quite a bit later than expected due recent work on GHC's CI and release infrastructure. See the GHC Blog [2] for more on this. As always, if anything looks amiss do let us know. Happy compiling! Cheers, - Ben [1] https://downloads.haskell.org/ghc/8.8.1-alpha1/docs/html/users_guide/8.8.1-… [2] https://www.haskell.org/ghc/blog/20190405-ghc-8.8-status.html

3 2

Linear Types: ready for review
by Spiwack, Arnaud 07 May '19

07 May '19

Dear GHC devs, The linear types patch is ready for review! https://gitlab.haskell.org/ghc/ghc/merge_requests/852 It is a fairly large patch (~3500loc of change to the compiler itself, with a ~2000loc diff on the testsuite). And it's gone through a lot of redesigns. The issue with a patch like this is that it is rather easy to get reviewer fatigue and just let things through. This is why I want to encourage as many people as possible to give a thorough review of part of the patch. Even 15 minutes of your time would be tremendously helpful! Here is what I suggest: pick a part of the compiler you know well, and look at how the patch affects it. If there is something that you don't understand let us know! Either in the MR discussion, or send an email to Krzysztof and me. We will answer and update the documentation. --- If you are still unsure where to start, here are what we consider to be the main entry points to the patch: - The file Multiplicity, which defines type Mult = Type, the Scaled type and functions unrestricted, linear, pattern synonyms One and Omega, quick submultiplicity test submult - The change to FunTy and new mkFunTy in TyCoRep, where the multiplicity argument is added - The change to funTyCon in TysPrim - The new unrestrictedFunTyCon and multiplicityTy in TysWiredIn - Var has now a new field varMult; functions such as updateVarTypeAndMult can be used to update multiplicity (e.g. when zonking). In Core, the multiplicity of a lambda is indicated by its varMult; multiplicity of a case expression is indicated by varMult of the case binder. - The functions mkDataConRepXin basicTypes/MkId and and dataConUserType function in basicTypes/DataCon, which are adding multiplicity variables to constructors. The change to wrapper_reqd means that all data constructors have a wrapper now. - The file UsageEnv defines a map from a variable to its multiplicity, used when typechecking - Calls to submult and tcSubMult, which guide multiplicity checking in the type checker - ensureSubMult and its calls, which guide multiplicity checking in Lint --- A more in-depth documentation and overview of the patch is on the wiki: https://gitlab.haskell.org/ghc/ghc/wikis/linear-types/implementation It has a table of contents which you can use as yet another way to find a starting point. --- If any of these resources are lacking, let us know too! We'll make sure to update them. --- Finally, I'll be holding a project session on Linear Types in ZüriHac next month. Where we can have further, more in-depth discussion about the patch, finalise its documentation, and address outstanding requests from reviews.

4 5