- ghc-devs - Haskell.org

Re: TTG: Handling Source Locations
by Ryan Scott 13 Feb '19

13 Feb '19

Yes, I agree. This will require sprinkling the codebase with EmptyCase due to [1], but that's still a sight better than calling `panic`. After GHC 8.10 is released (and the minimum version of GHC that HEAD supports is 8.8), we can even remove these empty cases by making the empty data type fields strict (see [2]). Ryan S. ----- [1] https://ghc.haskell.org/trac/ghc/ticket/15247#comment:4 [2] https://ghc.haskell.org/trac/ghc/ticket/15305

2 2

Re: TTG: Handling Source Locations
by Ryan Scott 13 Feb '19

13 Feb '19

> Yes, I have reported it while back. I don't know of the progress in fixing this. Reported what? #15884? [1] You do realize that there is a very simple workaround for that issue, right? Instead of writing this, which is subject to the pattern-guard completeness issues observed in #15753: f :: Maybe a -> Bool f (id->Nothing) = False f (id->(Just _)) = True You can instead write this: f :: Maybe a -> Bool f (id -> x) = case x of Nothing -> False Just _ -> True This will get proper coverage checking, which means that this technique could be used to remove all of the panicking catch-all cases brought about by dL view patterns. Ryan S. ----- [1] https://ghc.haskell.org/trac/ghc/ticket/15884 [2] https://ghc.haskell.org/trac/ghc/ticket/15753

1 0

TTG: Handling Source Locations
by Richard Eisenberg 12 Feb '19

12 Feb '19

Hi devs, I just came across [TTG: Handling Source Locations], as I was poking around in RdrHsSyn and found wondrous things like (dL->L wiz waz) all over the place. General outline: https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow/HandlingSou… <https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow/HandlingSou…> Phab diff: https://phabricator.haskell.org/D5036 <https://phabricator.haskell.org/D5036> Trac ticket: https://ghc.haskell.org/trac/ghc/ticket/15495 <https://ghc.haskell.org/trac/ghc/ticket/15495> Commit: https://gitlab.haskell.org/ghc/ghc/commit/509d5be69c7507ba5d0a5f39ffd1613a5… <https://gitlab.haskell.org/ghc/ghc/commit/509d5be69c7507ba5d0a5f39ffd1613a5…> I see why this change is wanted and how the new version works. It seems to me, though, that this move makes us *less typed*. That is, it would be very easy (and disastrous) to forget to match on a location node. For example, I can now do this: > foo :: LPat p -> ... > foo (VarPat ...) = ... Note that I have declared that foo takes a located pat, but then I forgot to extract the location with dL. This would type-check, but it would fail. Previously, the type checker would ensure that I didn't forget to match on the L constructor. This error would get caught after some poking about, because foo just wouldn't work. However, worse, we might forget to *add* a location when downstream functions expect one. This would be harder to detect, for two reasons: 1. The problem is caught at deconstruction, and figuring out where an object was constructed can be quite hard. 2. The problem might silently cause trouble, because dL won't actually fail on a node missing a location -- it just gives noSrcSpan. So the problem would manifest as a subtle degradation in the quality of an error message, perhaps not caught until several patches (or years!) later. So I'm uncomfortable with this direction of travel. Has this aspect of this design been brought up before? I have to say I don't have a great solution to suggest. Perhaps the best I can think of is to make Located a type family. It would branch on the type index to HsSyn types, introducing a Located node for GhcPass but not for other types. This Isn't really all that extensible (I think) and it gives special status to GHC's usage of the AST. But it seems to solve the immediate problems without the downside above. Sorry for reopening something that has already been debated, but (unless I'm missing something) the current state of affairs seems like a potential wellspring of subtle bugs. Thanks, Richard

6 11

RE: Performance of pattern synonyms
by Simon Peyton Jones 11 Feb '19

11 Feb '19

Are you as convinced as you were of the semantics of pattern synonyms? I can see they are the right semantics given a run-time implementation but the alternative compile-time implementation has a lot to recommend it. What exactly is "the alternative compile-time implementation"? Remember, although pattern synonyms are set up to call a matching function, that matching function is often inlined, which reduces the overhead to zero. I say "often" inlined. An INLINE pragma for pattern synonyms would be a good feature. Widening to ghc-devs. Simon From: Matthew Roberts <matthew.roberts(a)mq.edu.au> Sent: 11 February 2019 00:10 To: matthew.pickering(a)cs.ox.ac.uk; gergo(a)erdi.hu; Simon Peyton Jones <simonpj(a)microsoft.com>; rae(a)cs.brynmawr.edu Subject: Performance of pattern synonyms Hi all, I am working with someone on a compile-time pattern matching extension and the most important prior work is pattern synonyms in Haskell. I hope you might indulge a couple of questions I have not been able to answer myself from the literature: * [In my testing](http://pattern-benchmarks.herokuapp.com/posts/2019-02-09-peano.html<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fpattern-be…>), pattern synonyms have remarkable performance, has anyone ever benchmarked them before? * Do you have - on hand - the hackage data you used in investigating uses of pattern synonyms? I am looking for real-world usage of pattern matching extensions. * Are you as convinced as you were of the semantics of pattern synonyms? I can see they are the right semantics given a run-time implementation but the alternative compile-time implementation has a lot to recommend it. Thanks for your time, Matt Roberts Department of Computing, Macquarie University

3 2

RE: [commit: ghc] wip/T16188: testsuite: Report stdout and stderr in JUnit output (224fec6)
by Simon Peyton Jones 11 Feb '19

11 Feb '19

Are these commits really for #16188? For which we have a MR in progress https://gitlab.haskell.org/ghc/ghc/merge_requests/207 I was just surprised to see wip/T16188 going by. Simon | -----Original Message----- | From: ghc-commits <ghc-commits-bounces(a)haskell.org> On Behalf Of | git(a)git.haskell.org | Sent: 10 February 2019 21:32 | To: ghc-commits(a)haskell.org | Subject: [commit: ghc] wip/T16188: testsuite: Report stdout and stderr in | JUnit output (224fec6) | | Repository : ssh://git@git.haskell.org/ghc | | On branch : wip/T16188 | Link : | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.hask | ell.org%2Ftrac%2Fghc%2Fchangeset%2F224fec6983e16ecfc44a80d47e591a2425468e | af%2Fghc&data=02%7C01%7Csimonpj%40microsoft.com%7Cec8ee4f808cd416cf0d | d08d68f9f2e48%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C63685431128635 | 6725&sdata=ZS4Bp%2FMsebLALA27waYiWgtyx%2FyrKSkiCLcFXvSfXBE%3D&res | erved=0 | | >--------------------------------------------------------------- | | commit 224fec6983e16ecfc44a80d47e591a2425468eaf | Author: Ben Gamari <ben(a)smart-cactus.org> | Date: Thu Jan 24 14:20:11 2019 -0500 | | testsuite: Report stdout and stderr in JUnit output | | This patch makes the JUnit output more useful as now we also report | the | stdout/stderr in the message which can be used to quickly identify | why a | test is failing without downloading the log. | | This also introduces TestResult, | previously we were simply passing around tuples, making things the | implementation rather difficult to follow and harder to extend. | | | >--------------------------------------------------------------- | | 224fec6983e16ecfc44a80d47e591a2425468eaf | testsuite/driver/junit.py | 23 ++++++++-------- | testsuite/driver/testglobals.py | 15 +++++++++++ | testsuite/driver/testlib.py | 58 ++++++++++++++++++++++++++--------- | ------ | testsuite/driver/testutil.py | 7 +++-- | 4 files changed, 69 insertions(+), 34 deletions(-) | | Diff suppressed because of size. To see it, use: | | git diff-tree --root --patch-with-stat --no-color --find-copies- | harder --ignore-space-at-eol --cc | 224fec6983e16ecfc44a80d47e591a2425468eaf | _______________________________________________ | ghc-commits mailing list | ghc-commits(a)haskell.org | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.has | kell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc- | commits&data=02%7C01%7Csimonpj%40microsoft.com%7Cec8ee4f808cd416cf0dd | 08d68f9f2e48%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636854311286366 | 720&sdata=RH6Jnvs7cNsnGyLpwONSZ0Cldighb85HZtuWfn4Gc9Q%3D&reserved | =0

2 1

Commit comments - call for opinions
by Tobias Dammers 11 Feb '19

11 Feb '19

Dear all, So far, we had a feature in Trac where git commit messages mentioning a ticket would automatically be copied into a comment on that commit. See, for example, this comment: https://ghc.haskell.org/trac/ghc/ticket/13615#comment:47 GitLab does things slightly differently. It has "live" git repository information available, and rather than the relatively static comment list we see in Trac, it synthesizes a "timeline" style list of events relevant to an issue, which includes comments ("notes"), but also issue status updates, git commits, and other things. So when a commit mentions a GitLab issue, then GitLab will insert a link to that commit into the issue's event timeline. This means that in principle, copying commit messages into notes would be redundant, and we initially decided to ignore commit comments during the Trac/GitLab migration. However, it also means that the issue timeline will no longer display the actual commit message anymore, just a link to the commit ("@username mentioned this issue in commit 1234beef" or similar). So what used to be a narrative that you could read top-down to retrace the issue's history is now a bit more scattered. Now, the ideal solution would be for GitLab to instead display the full commit message, but I don't see this happening anytime soon, because it would require a patch to GitLab itself. So we're left with two options: a) Import commit comments as notes, duplicating the commit message into the note, and having both the full commit note and a hyperlinked commit reference in the issue timeline. b) Don't import commit comments as notes, just rely on GitLab to insert the hyperlinked commit reference. If any of you have any preference either way, please do tell. Thanks! -- Tobias Dammers - tdammers(a)gmail.com

5 5

Memory ordering and thunk update
by Ben Gamari 10 Feb '19

10 Feb '19

Hi Simon and Peter, I just wanted to draw your attention to !337 [1], where I try to fix #15994. While it's possible I have missed something, it looks to me like there has been a bug lurking here for quite some time. In particular on a weak memory model machine we do not place a write barrier between the construction of the result of a thunk evaluation and making the results visible to other cores via the indirection's indirectee field. This essentially means that a thread looking at the indirectee may essentially see uninitialized memory. Specifically, updateWithIndirection is currently: # Evaluation result p2 initialized by caller ... ((StgInd *)p1)->indirectee = p2; write_barrier(); SET_INFO(p1, &stg_BLACKHOLE_info); ... whereas I think this should rather be # Evaluation result p2 initialized by caller ... write_barrier(); ((StgInd *)p1)->indirectee = p2; SET_INFO(p1, &stg_BLACKHOLE_info); ... I describe the reasoning for this in more detail in the Note added in !337. All-in-all, I'm rather surprised to find this bug. While we won't see this issue manifest on x86_64 due to this architecture's memory model, we have long supported ARM, PowerPC, and SPARC, all of which have weakly-ordered execution modes. I can't find any relevant open tickets from these platforms. The fact that this wasn't noticed on these platforms makes me wonder whether I am just missing something. Let me know what you think. Cheers, - Ben [1] https://gitlab.haskell.org/ghc/ghc/merge_requests/337

1 0

RE: Cannot build with Hadrian
by Andrey Mokhov 09 Feb '19

09 Feb '19

Hi Eric, Good to hear you managed to build GHC both with Make and Hadrian. Best wishes with your first GHC patch! Cheers, Andrey From: Eric Crockett [mailto:ecrockett0@gmail.com] Sent: 09 February 2019 18:21 To: Andrey Mokhov <andrey.mokhov(a)newcastle.ac.uk> Subject: Re: Cannot build with Hadrian Andrey, I had already deleted the folder and tried again with make, which was successful. But since I sent the email, I figured I'd try again with hadrian as well. I followed exactly what I did above (which is what I did the first time, too) and it worked fine. *shrug* Thanks anyway! Eric On Sat, Feb 9, 2019 at 5:03 AM Andrey Mokhov <andrey.mokhov(a)newcastle.ac.uk<mailto:andrey.mokhov@newcastle.ac.uk>> wrote: Hi Eric, Can you show the contents of the "libffi-tarballs" directory in your GHC tree? This error says it expects exactly one libffi tarball to be there, but it got either 0 or more than 1. I guess there is just no tarball there in your case. Perhaps git clone failed to complete properly? Cheers, Andrey ------------------------------ Message: 3 Date: Fri, 8 Feb 2019 21:57:03 -0800 From: Eric Crockett <ecrockett0(a)gmail.com<mailto:ecrockett0@gmail.com>> To: ghc-devs <ghc-devs(a)haskell.org<mailto:ghc-devs@haskell.org>> Subject: Cannot build with Hadrian Message-ID: <CAApao_=RAyyXnBgL=KBdwgb1mLAWgiCsJok6unVhchY+uLBbTQ(a)mail.gmail.com<mailto:KBdwgb1mLAWgiCsJok6unVhchY%2BuLBbTQ@mail.gmail.com>> Content-Type: text/plain; charset="utf-8" GHC newcomer here -- attempting to work on my first patch. I decided to try Hadrian, but ran into a problem. I think I obtained the source using > git clone --recursive https://gitlab.haskell.org/ghc/ghc Then: > ./boot && ./configure > hadrian/build.sh -j --flavour=devel2 This ran for maybe 15 minutes, then showed the error below. Apparently I ended up with too many tarballs? Any suggestions? Thanks, Eric ... ... | Run Ghc CompileCWithGhc Stage1: rts/Inlines.c => > _build/stage1/rts/build/c/Inlines.thr_o > | Run Cc FindCDependencies Stage1: rts/Compact.cmm => > _build/stage1/rts/build/cmm/Compact.o.d > | Run Cc FindCDependencies Stage1: rts/PathUtils.c => > _build/stage1/rts/build/c/PathUtils.o.d > | Run Ghc CompileHs Stage1: rts/Compact.cmm => > _build/stage1/rts/build/cmm/Compact.o > | Run Ghc CompileCWithGhc Stage1: rts/PathUtils.c => > _build/stage1/rts/build/c/PathUtils.o > | Remove file _build/stage1/rts/build/libHSrts-1.0.a > | Run Ar Pack Stage1: _build/stage1/rts/build/c/Adjustor.o (and 113 more) > => _build/stage1/rts/build/libHSrts-1.0.a > /usr/bin/ar: creating _build/stage1/rts/build/libHSrts-1.0.a > /---------------------------------------------------\ > | Successfully built library 'rts' (Stage1, way v). | > | Library: _build/stage1/rts/build/libHSrts-1.0.a | > \---------------------------------------------------/ > | Remove file _build/stage1/rts/build/libHSrts-1.0_thr.a > | Run Ar Pack Stage1: _build/stage1/rts/build/c/Adjustor.thr_o (and 115 > more) => _build/stage1/rts/build/libHSrts-1.0_thr.a > /usr/bin/ar: creating _build/stage1/rts/build/libHSrts-1.0_thr.a > /-----------------------------------------------------\ > | Successfully built library 'rts' (Stage1, way thr). | > | Library: _build/stage1/rts/build/libHSrts-1.0_thr.a | > \-----------------------------------------------------/ > | Copy file: _build/generated/ghcplatform.h => > _build/stage1/rts/build/ghcplatform.h > | Copy file: _build/generated/ghcversion.h => > _build/stage1/rts/build/ghcversion.h > | Copy file: _build/generated/DerivedConstants.h => > _build/stage1/rts/build/DerivedConstants.h > | Copy file: _build/generated/ghcautoconf.h => > _build/stage1/rts/build/ghcautoconf.h > | Remove directory _build/stage1/libffi/build > shakeArgsWith 0.000s 0% > Function shake 0.005s 0% > Database read 0.000s 0% > With database 0.000s 0% > Running rules 548.377s 99% ========================= > Total 548.383s 100% > Error when running Shake build system: > at src/Rules.hs:(35,19)-(52,17): > at src/Rules.hs:52:5-17: > * Depends on: _build/stage1/lib/package.conf.d/rts-1.0.conf > at src/Rules/Register.hs:(94,9)-(98,34): > * Depends on: _build/stage1/rts/build/ffi.h > at src/Rules/Libffi.hs:(49,7)-(52,48): > * Depends on: _build/stage1/rts/build/ffi.h > _build/stage1/rts/build/ffitarget.h > at src/Rules/Libffi.hs:52:13-48: > * Depends on: _build/stage1/libffi/build/inst/lib/libffi.a > at src/Hadrian/Builder.hs:70:5-23: > * Depends on: _build/stage1/libffi/build/Makefile > at src/Rules/Libffi.hs:107:9-27: > * Depends on: _build/stage1/libffi/build/Makefile.in > * Raised the exception: > Exactly one LibFFI tarball is expected > CallStack (from HasCallStack): > error, called at src/Hadrian/Utilities.hs:60:27 in main:Hadrian.Utilities -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190208/87482224/at…> ------------------------------ Subject: Digest Footer _______________________________________________ ghc-devs mailing list ghc-devs(a)haskell.org<mailto:ghc-devs@haskell.org> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs ------------------------------ End of ghc-devs Digest, Vol 186, Issue 9 ****************************************

1 0

RE: Cannot build with Hadrian
by Andrey Mokhov 09 Feb '19

09 Feb '19

Hi Eric, Can you show the contents of the "libffi-tarballs" directory in your GHC tree? This error says it expects exactly one libffi tarball to be there, but it got either 0 or more than 1. I guess there is just no tarball there in your case. Perhaps git clone failed to complete properly? Cheers, Andrey ------------------------------ Message: 3 Date: Fri, 8 Feb 2019 21:57:03 -0800 From: Eric Crockett <ecrockett0(a)gmail.com> To: ghc-devs <ghc-devs(a)haskell.org> Subject: Cannot build with Hadrian Message-ID: <CAApao_=RAyyXnBgL=KBdwgb1mLAWgiCsJok6unVhchY+uLBbTQ(a)mail.gmail.com> Content-Type: text/plain; charset="utf-8" GHC newcomer here -- attempting to work on my first patch. I decided to try Hadrian, but ran into a problem. I think I obtained the source using > git clone --recursive https://gitlab.haskell.org/ghc/ghc Then: > ./boot && ./configure > hadrian/build.sh -j --flavour=devel2 This ran for maybe 15 minutes, then showed the error below. Apparently I ended up with too many tarballs? Any suggestions? Thanks, Eric ... ... | Run Ghc CompileCWithGhc Stage1: rts/Inlines.c => > _build/stage1/rts/build/c/Inlines.thr_o > | Run Cc FindCDependencies Stage1: rts/Compact.cmm => > _build/stage1/rts/build/cmm/Compact.o.d > | Run Cc FindCDependencies Stage1: rts/PathUtils.c => > _build/stage1/rts/build/c/PathUtils.o.d > | Run Ghc CompileHs Stage1: rts/Compact.cmm => > _build/stage1/rts/build/cmm/Compact.o > | Run Ghc CompileCWithGhc Stage1: rts/PathUtils.c => > _build/stage1/rts/build/c/PathUtils.o > | Remove file _build/stage1/rts/build/libHSrts-1.0.a > | Run Ar Pack Stage1: _build/stage1/rts/build/c/Adjustor.o (and 113 more) > => _build/stage1/rts/build/libHSrts-1.0.a > /usr/bin/ar: creating _build/stage1/rts/build/libHSrts-1.0.a > /---------------------------------------------------\ > | Successfully built library 'rts' (Stage1, way v). | > | Library: _build/stage1/rts/build/libHSrts-1.0.a | > \---------------------------------------------------/ > | Remove file _build/stage1/rts/build/libHSrts-1.0_thr.a > | Run Ar Pack Stage1: _build/stage1/rts/build/c/Adjustor.thr_o (and 115 > more) => _build/stage1/rts/build/libHSrts-1.0_thr.a > /usr/bin/ar: creating _build/stage1/rts/build/libHSrts-1.0_thr.a > /-----------------------------------------------------\ > | Successfully built library 'rts' (Stage1, way thr). | > | Library: _build/stage1/rts/build/libHSrts-1.0_thr.a | > \-----------------------------------------------------/ > | Copy file: _build/generated/ghcplatform.h => > _build/stage1/rts/build/ghcplatform.h > | Copy file: _build/generated/ghcversion.h => > _build/stage1/rts/build/ghcversion.h > | Copy file: _build/generated/DerivedConstants.h => > _build/stage1/rts/build/DerivedConstants.h > | Copy file: _build/generated/ghcautoconf.h => > _build/stage1/rts/build/ghcautoconf.h > | Remove directory _build/stage1/libffi/build > shakeArgsWith 0.000s 0% > Function shake 0.005s 0% > Database read 0.000s 0% > With database 0.000s 0% > Running rules 548.377s 99% ========================= > Total 548.383s 100% > Error when running Shake build system: > at src/Rules.hs:(35,19)-(52,17): > at src/Rules.hs:52:5-17: > * Depends on: _build/stage1/lib/package.conf.d/rts-1.0.conf > at src/Rules/Register.hs:(94,9)-(98,34): > * Depends on: _build/stage1/rts/build/ffi.h > at src/Rules/Libffi.hs:(49,7)-(52,48): > * Depends on: _build/stage1/rts/build/ffi.h > _build/stage1/rts/build/ffitarget.h > at src/Rules/Libffi.hs:52:13-48: > * Depends on: _build/stage1/libffi/build/inst/lib/libffi.a > at src/Hadrian/Builder.hs:70:5-23: > * Depends on: _build/stage1/libffi/build/Makefile > at src/Rules/Libffi.hs:107:9-27: > * Depends on: _build/stage1/libffi/build/Makefile.in > * Raised the exception: > Exactly one LibFFI tarball is expected > CallStack (from HasCallStack): > error, called at src/Hadrian/Utilities.hs:60:27 in main:Hadrian.Utilities -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190208/87482224/at…> ------------------------------ Subject: Digest Footer _______________________________________________ ghc-devs mailing list ghc-devs(a)haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs ------------------------------ End of ghc-devs Digest, Vol 186, Issue 9 ****************************************

1 0

Cannot build with Hadrian
by Eric Crockett 09 Feb '19

09 Feb '19

GHC newcomer here -- attempting to work on my first patch. I decided to try Hadrian, but ran into a problem. I think I obtained the source using > git clone --recursive https://gitlab.haskell.org/ghc/ghc Then: > ./boot && ./configure > hadrian/build.sh -j --flavour=devel2 This ran for maybe 15 minutes, then showed the error below. Apparently I ended up with too many tarballs? Any suggestions? Thanks, Eric ... ... | Run Ghc CompileCWithGhc Stage1: rts/Inlines.c => > _build/stage1/rts/build/c/Inlines.thr_o > | Run Cc FindCDependencies Stage1: rts/Compact.cmm => > _build/stage1/rts/build/cmm/Compact.o.d > | Run Cc FindCDependencies Stage1: rts/PathUtils.c => > _build/stage1/rts/build/c/PathUtils.o.d > | Run Ghc CompileHs Stage1: rts/Compact.cmm => > _build/stage1/rts/build/cmm/Compact.o > | Run Ghc CompileCWithGhc Stage1: rts/PathUtils.c => > _build/stage1/rts/build/c/PathUtils.o > | Remove file _build/stage1/rts/build/libHSrts-1.0.a > | Run Ar Pack Stage1: _build/stage1/rts/build/c/Adjustor.o (and 113 more) > => _build/stage1/rts/build/libHSrts-1.0.a > /usr/bin/ar: creating _build/stage1/rts/build/libHSrts-1.0.a > /---------------------------------------------------\ > | Successfully built library 'rts' (Stage1, way v). | > | Library: _build/stage1/rts/build/libHSrts-1.0.a | > \---------------------------------------------------/ > | Remove file _build/stage1/rts/build/libHSrts-1.0_thr.a > | Run Ar Pack Stage1: _build/stage1/rts/build/c/Adjustor.thr_o (and 115 > more) => _build/stage1/rts/build/libHSrts-1.0_thr.a > /usr/bin/ar: creating _build/stage1/rts/build/libHSrts-1.0_thr.a > /-----------------------------------------------------\ > | Successfully built library 'rts' (Stage1, way thr). | > | Library: _build/stage1/rts/build/libHSrts-1.0_thr.a | > \-----------------------------------------------------/ > | Copy file: _build/generated/ghcplatform.h => > _build/stage1/rts/build/ghcplatform.h > | Copy file: _build/generated/ghcversion.h => > _build/stage1/rts/build/ghcversion.h > | Copy file: _build/generated/DerivedConstants.h => > _build/stage1/rts/build/DerivedConstants.h > | Copy file: _build/generated/ghcautoconf.h => > _build/stage1/rts/build/ghcautoconf.h > | Remove directory _build/stage1/libffi/build > shakeArgsWith 0.000s 0% > Function shake 0.005s 0% > Database read 0.000s 0% > With database 0.000s 0% > Running rules 548.377s 99% ========================= > Total 548.383s 100% > Error when running Shake build system: > at src/Rules.hs:(35,19)-(52,17): > at src/Rules.hs:52:5-17: > * Depends on: _build/stage1/lib/package.conf.d/rts-1.0.conf > at src/Rules/Register.hs:(94,9)-(98,34): > * Depends on: _build/stage1/rts/build/ffi.h > at src/Rules/Libffi.hs:(49,7)-(52,48): > * Depends on: _build/stage1/rts/build/ffi.h > _build/stage1/rts/build/ffitarget.h > at src/Rules/Libffi.hs:52:13-48: > * Depends on: _build/stage1/libffi/build/inst/lib/libffi.a > at src/Hadrian/Builder.hs:70:5-23: > * Depends on: _build/stage1/libffi/build/Makefile > at src/Rules/Libffi.hs:107:9-27: > * Depends on: _build/stage1/libffi/build/Makefile.in > * Raised the exception: > Exactly one LibFFI tarball is expected > CallStack (from HasCallStack): > error, called at src/Hadrian/Utilities.hs:60:27 in main:Hadrian.Utilities

1 0