| Hmm, I suspect this means that you (or perhaps just this key?) don't | have push permission to the haskell.org Haddock repository. We should | rectify this. Herbert, could you verify this when you get a chance? I'm sure I used to be able to. I know I've done this before. | > What now? I attach the patch if someone else would like to push. If | > you do, update ghc HEAD to match | | I'll take care of this. Thanks. All builds currently broken because of this.. my fault, sorry! Simon

| if you look in the 'packages' text-file at the top of GHC's source-tree, | you'll notice that haddock's upstream repo is declared as | ssh://git@github.com/haskell/haddock.git | | And you should have permission to push there. Oh yes, thanks -- I'd forgotten that AGAIN. I have now pushed to both the Haddock repo, and the submodule update to master. I hope that should settle things. Ben you can stand down. Simon

| tests/alloc/haddock.Cabal  11811321368  + 6.40%  12567003040 | bytes | tests/alloc/haddock.compiler  60211764264  + 7.39% | 64658444232  bytes | | The haddock stats changes are probably genuine, I assume, but the | expected value in all.T should be updated. | I'm sad about this. My changes should have had no visible performance impact. But I'm not set up to dig into why this one patch might have had such large impact on Haddock. Presumably it's not Haddock per-se but perhaps the GHC session that it invokes. I am not sure what to do... I'm quite reluctant to cause a 7% regression in allocation without investigation. I suppose I or someone should investigate before-and-after, but I don't have time to do that this week. If someone felt able to have a go, that'd be fantastic. Otherwise let's at least make a ticket. For the record, the series of patches, one of which presumably causes the regression, is below. Bisecting to the right one would be very helpful -- but you have to apply the final one (haddock-update) first. Sigh. I should be more careful. Simon commit d55a9b4fd5a3ce24b13311962bca66155b17a558 Author: Simon Peyton Jones <simonpj@microsoft.com> Date: Mon Jun 13 18:28:30 2016 +0100 Update Haddock to follow change in LHsSigWcType Update submodule to accompany this commit: commit 15b9bf4ba4ab47e6809bf2b3b36ec16e502aea72 Author: Simon Peyton Jones <simonpj@microsoft.com> Date: Sat Jun 11 23:49:27 2016 +0100 Improve typechecking of let-bindings Sorry it's late! commit 0497ee504cc9ac5d6babee9b98bf779b3fc50b98 Author: Bartosz Nitka <niteria@gmail.com> Date: Thu Jun 9 08:50:32 2016 -0700 Make the Ord Module independent of Unique order The `Ord Module` instance currently uses `Unique`s for comparison. We don't want to use the `Unique` order because it can introduce nondeterminism. This switches `Ord ModuleName` and `Ord UnitId` to use lexicographic ordering making `Ord Module` deterministic transitively. I've run `nofib` and it doesn't make a measurable difference. See also Note [ModuleEnv determinism and performance]. Test Plan: ./validate run nofib: P112 Reviewers: simonpj, simonmar, austin, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2030 GHC Trac Issues: #4012 commit 586d55815401c54f4687d053fb033e53865e0bf1 Author: Bartosz Nitka <niteria@gmail.com> Date: Mon Jun 13 07:35:32 2016 -0700 Use UniqFM for SigOf Summary: The Ord instance for ModuleName is currently implemented in terms of Uniques causing potential determinism problems. I plan to change it to use the actual FastStrings and in preparation for that I'm switching to UniqFM where it's possible (you need *one* Unique per key, and you can't get the keys back), so that the performance doesn't suffer. Test Plan: ./validate Reviewers: simonmar, austin, ezyang, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2320 GHC Trac Issues: #4012 commit 7de776cfe7825fca6a71fe6b3854c3c86bf9ca12 Author: Bartosz Nitka <niteria@gmail.com> Date: Mon Jun 13 04:53:43 2016 -0700 Kill unused foldModuleEnv With the current implementation, it's nondeterministic because Ord Module is nondeterministic. commit 5cee88d766723929f789ffcd2ef24d8b5ef62a16 Author: Tamar Christina <tamar@zhox.com> Date: Mon Jun 13 13:29:17 2016 +0200 Add thin library support to Windows too Summary: Code already existed in the RTS to add thin library support for non-Windows operating systems. This adds it to Windows as well. ar thin libraries have the exact same format as normal archives except they have a different magic string and they don't copy the object files into the archive. Instead each header entry points to the location of the object file on disk. This is useful when a library is only created to satisfy a compile time dependency instead of to be distributed. This saves the time required for copying. Test Plan: ./validate and new test T11788 Reviewers: austin, bgamari, simonmar, erikd Reviewed By: bgamari, simonmar Subscribers: thomie, #ghc_windows_task_force Differential Revision: https://phabricator.haskell.org/D2323 GHC Trac Issues: #11788 commit 1dcb32ddba605bced2e0e0ce3f52b58e8ff33f5b Author: Simon Peyton Jones <simonpj@microsoft.com> Date: Mon Jun 13 12:02:54 2016 +0100 A second test for Trac #12055 This one omits the extension, thereby making GHC 8.0 produce "GHC internal error". commit 921ebc9f0854d033cbafd43d3b2c5ba679c27b3c Author: Simon Peyton Jones <simonpj@microsoft.com> Date: Mon Jun 13 11:56:44 2016 +0100 Test Trac #12055 commit e064f501d76c208ddab3c3be551ffe5167d7974f Author: Simon Peyton Jones <simonpj@microsoft.com> Date: Sun Jun 12 22:32:31 2016 +0100 Add to .gitignore This adds *.patch *.stackdump (Windows) foo* (simonpj uses foo* for junk files) commit 8104f7c674d7ef2db0c25312f48763202dcef57f Author: Simon Peyton Jones <simonpj@microsoft.com> Date: Sun Jun 12 22:01:49 2016 +0100 Remove some traceTc calls During the kind-checking "knot" we have to be careful not to print too eagerly. commit 599d912f0b85583e389661d85ed2f198e2621bb0 Author: Simon Peyton Jones <simonpj@microsoft.com> Date: Sun Jun 12 00:06:31 2016 +0100 Beef up isPredTy isPredTy can be called on ill-kinded types, especially (of course) if there is a kind error. We don't wnat it to crash, but it was, in piResultTy. This patch introduces piResultTy_maybe, and uses it in isPredTy. Ugh. I dislike this code. It's mainly used to know when we should print types with '=>', and we should probably have a better way to signal that. commit 15fc52819c440f9e9b91ce92fcfda3c264cbe1c1 Author: Simon Peyton Jones <simonpj@microsoft.com> Date: Sun Jun 12 00:04:30 2016 +0100 Fix the in-scope set for extendTvSubstWithClone We'd forgotten the variables free in the kind. Ditto extendCvSubstWithClone commit 1f661281a23b6eab83a1144c43e464c0e2d2195a Author: Simon Peyton Jones <simonpj@microsoft.com> Date: Sun Jun 12 00:00:53 2016 +0100 Beef up mkNakedCastTy By spotting Refl coercions we can avoid building an awful lot of CastTys. Simple and effective. commit 35c9de7ca053eda472cb446c53bcd2007bfd8394 Author: Simon Peyton Jones <simonpj@microsoft.com> Date: Sat Jun 11 23:56:42 2016 +0100 Move the constraint-kind validity check For type synonyms, we need to check that if the RHS has kind Constraint, then we have -XConstraintKinds. For some reason this was done in checkValidType, but it makes more sense to do it in checkValidTyCon. I can't remember quite why I made this change; maybe it fixes a Trac ticket, but if so I forget which. But it's a modest improvement anyway. commit 7afb7adf45216701e4f645676ecc0668f64b424d Author: Simon Peyton Jones <simonpj@microsoft.com> Date: Sat Jun 11 23:55:10 2016 +0100 Get in-scope set right in top_instantiate ...thereby being able to replace substThetaUnchecked with substTheta commit c28dde37f3f274a2a1207dd4e175ea79769f5ead Author: Simon Peyton Jones <simonpj@microsoft.com> Date: Sat Jun 11 23:51:44 2016 +0100 Tidy up zonkQuantifiedTyVar I managed to eliminate the strange zonkQuantifiedTyVarOrType, which is no longer used. commit 15b9bf4ba4ab47e6809bf2b3b36ec16e502aea72 Author: Simon Peyton Jones <simonpj@microsoft.com> Date: Sat Jun 11 23:49:27 2016 +0100 Improve typechecking of let-bindings This major commit was initially triggered by #11339, but it spiraled into a major review of the way in which type signatures for bindings are handled, especially partial type signatures. On the way I fixed a number of other bugs, namely #12069 #12033 #11700 #11339 #11670 The main change is that I completely reorganised the way in which type signatures in bindings are handled. The new story is in TcSigs Note [Overview of type signatures]. Some specific: * Changes in the data types for signatures in TcRnTypes: TcIdSigInfo and new TcIdSigInst * New module TcSigs deals with typechecking type signatures and pragmas. It contains code mostly moved from TcBinds, which is already too big * HsTypes: I swapped the nesting of HsWildCardBndrs and HsImplicitBndsrs, so that the wildcards are on the oustide not the insidde in a LHsSigWcType. This is just a matter of convenient, nothing deep. There are a host of other changes as knock-on effects, and it all took FAR longer than I anticipated :-). But it is a significant improvement, I think. Lots of error messages changed slightly, some just variants but some modest improvements. New tests * typecheck/should_compile * SigTyVars: a scoped-tyvar test * ExPat, ExPatFail: existential pattern bindings * T12069 * T11700 * T11339 * partial-sigs/should_compile * T12033 * T11339a * T11670 One thing to check: * Small change to output from ghc-api/landmines. Need to check with Alan Zimmerman

Hi, Am Dienstag, den 14.06.2016, 08:18 +0000 schrieb Simon Peyton Jones:

For the record, the series of patches, one of which presumably causes the regression, is below.   Bisecting to the right one would be very helpful -- but you have to apply the final one (haddock-update) first.

I added a hack to the script that runs perf.haskell.org to cherry-pick this final patch if it is told to build something from that version range, and re-started the build of the affected commits. This should narrow it down. Will report back. Greetings, Joachim -- Joachim “nomeata” Breitner   mail@joachim-breitner.de • https://www.joachim-breitner.de/   XMPP: nomeata@joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F   Debian Developer: nomeata@debian.org