December 2018 - ghc-devs

GitLab migration status
by Ben Gamari 18 Dec '18

18 Dec '18

TL;DR. Given somewhat slower-than-expected progress on the Trac import I suggest that we implement a pared-down migration on Tuesday. See "The Plan" below. Hello everyone, Over the last few weeks we have been hard at work preparing the migration to GitLab. Currently the following things are ready: * Hosting of GHC's repositories and those of its mirrors have been prepared. * Continuous integration has been configured for GHC. All-in-all the GitLab migration has been quite timely since we were recently notified by CircleCI of billing changes which will soon make it quite difficult for us to continue using their services (see the thread on ghc-devops for details). Thankfully, moving CI to GitLab has been mostly painless and has even enabled us to introduce testing of platforms which were previously inaccessible to us under CircleCI. * The various linters which previously ran via `arc lint` and gitolite post-receive hooks have been ported to CI jobs. * The Trac ticket migration is looking good although there are still a significant number of details which need to be sorted out. * The Wiki migration is in a similar state. Over the past weeks we have been in constant contact with GitLab's FOSS outreach group, who have been quite helpful in getting the eyes of GitLab employees on the issues affecting our transition. Thanks to especially to David Planella for his help so far. Unfortunately, there is one issue in particular [1] which is currently blocking the Trac migration. From my discussions with GitLab's upstream it sounds like it may be possible for them to prioritize a fix in the short-term. However, our aggressive migration timeline is a fair bit faster than GitLab's development cycle and consequently this certainly won't happen before our planned migration on Tuesday. # The Plan Given what remains to be done in the Trac migration I believe it would be a mistake to move ahead with the full migration as planned. However, in the interest of re-gaining functional continuous integration of patches as soon as possible I propose that we move ahead with moving code review on Tuesday. The plan would be as follows: 1. We setup the final gitlab.haskell.org instance tomorrow; since the Trac migration will not be run will need to create new accounts on instance. 2. We begin officially accepting merge requests on this fresh GitLab instance on Tuesday. At this point gitlab.haskell.org:ghc/ghc will become GHC's official upstream repository. 3. We allow a week of transition time where new Differentials will continue to be accepted via Phabricator. 4. After this transition period we place Phabricator in read-only mode. 5. When we are confident in the Trac migration (likely after the new year) we move ahead with importing tickets and the wiki Previously I was skeptical of any plan that involved running the Trac migration against a live GitLab instance. However, further reflection I believe such a migration is safe and feasible. Moreover, given the constraints set upon us by the impending CircleCI changes, I think this is our best option to ensure continuity of CI. Thoughts? Cheers, - Ben [1] https://gitlab.com/gitlab-org/gitlab-ce/issues/46980

6 7

Windows failures
by Simon Peyton Jones 16 Dec '18

16 Dec '18

Tamar Things are getting better. Here's my list of testsuite failure on Windows, based on last night's HEAD. Still 16 failures. Simon Unexpected failures: plugins/plugin-recomp-change.run plugin-recomp-change [bad exit code] (normal) rts/T10672/T10672_x64.run T10672_x64 [bad exit code] (normal) simplCore/should_compile/T7702.run T7702 [exit code non-0] (normal) th/T10596.run T10596 [exit code non-0] (normal) th/TH_spliceE1.run TH_spliceE1 [exit code non-0] (ext-interp) th/TH_PromotedList.run TH_PromotedList [exit code non-0] (ext-interp) libraries/Win32/tests/T4452.run T4452 [bad exit code] (normal) plugins/plugins07.run plugins07 [bad exit code] (normal) plugins/plugins09.run plugins09 [bad exit code] (normal) plugins/plugins10.run plugins10 [bad stdout] (normal) plugins/plugins11.run plugins11 [bad stdout] (normal) plugins/T10420.run T10420 [bad exit code] (normal) plugins/T10294a.run T10294a [bad exit code] (normal) plugins/plugin-recomp-pure.run plugin-recomp-pure [bad exit code] (normal) plugins/plugin-recomp-impure.run plugin-recomp-impure [bad exit code] (normal) plugins/plugin-recomp-flags.run plugin-recomp-flags [bad exit code] (normal)

2 1

Fwd: [commit: ghc] master: Use https links in user-facing startup and error messages (a1c0b70)
by Sylvain Henry 15 Dec '18

15 Dec '18

Hi Ben, I've just noticed that when you commit a diff from phab (as below), you are assigned both as committer and *author* (see also here https://git.haskell.org/ghc.git/commitdiff/a1c0b70638949a73bbd404c11797f2ed…) Reviewers and subscribers to the phab diff are indicated in the commit message but not the author (here Ingo Blechschmidt "iblech"). I'm worried that if the Phabricator instance goes down we won't be able to retrieve commit authors. And also that they are not credited appropriately (cf git shortlog -sne). (By the way, I've also noticed that .mailmap contents isn't up to date: `git shortlog -se | cut -f2 | cut -d'<' -f1 | uniq -d` isn't empty. Maybe you could add a check in a script somewhere to ensure that it stays empty when you push a commit?). Regards, Sylvain -------- Forwarded Message -------- Subject: [commit: ghc] master: Use https links in user-facing startup and error messages (a1c0b70) Date: Sat, 15 Dec 2018 00:49:47 +0000 (UTC) From: git(a)git.haskell.org Reply-To: ghc-devs(a)haskell.org To: ghc-commits(a)haskell.org Repository : ssh://git@git.haskell.org/ghc On branch : master Link : http://ghc.haskell.org/trac/ghc/changeset/a1c0b70638949a73bbd404c11797f2edf… > --------------------------------------------------------------- commit a1c0b70638949a73bbd404c11797f2edf28f5965 Author: Ben Gamari <ben(a)smart-cactus.org> Date: Fri Dec 14 11:10:56 2018 -0500 Use https links in user-facing startup and error messages I consider myself lucky that in my circle of friends, `http` urls (as opposed to `https` urls) are frowned upon in that we generally apologize in the rase cases that we share an `http` url. This pull request changes `http` links into their `https` analogues in the following places: * In the GHCI startup message (and parts of the User's Guide, where there are verbatim transcripts of GHCi sessions). * In a couple of error messages, asking the user to report a bug. (I also took the liberty to change a single space before the reportabug url into two spaces, harmonizing this occurence with the others.) I'm not trying to start a war. I just had a moment to spare and felt like preparing this diff. Merge or don't merge as you wish! Reviewers: bgamari, erikd, simonmar Subscribers: goldfire, rwbarton, carter Differential Revision: https://phabricator.haskell.org/D5450 > --------------------------------------------------------------- a1c0b70638949a73bbd404c11797f2edf28f5965 compiler/typecheck/TcTyClsDecls.hs | 2 +- compiler/utils/Panic.hs | 2 +- docs/users_guide/ghci.rst | 4 ++-- ghc/GHCi/UI.hs | 2 +- rts/RtsMessages.c | 2 +- 5 files changed, 6 insertions(+), 6 deletions(-) diff --git a/compiler/typecheck/TcTyClsDecls.hs b/compiler/typecheck/TcTyClsDecls.hs index cc9779a..71899a1 100644 --- a/compiler/typecheck/TcTyClsDecls.hs +++ b/compiler/typecheck/TcTyClsDecls.hs @@ -3609,7 +3609,7 @@ checkValidRoles tc report_error doc = addErrTc $ vcat [text "Internal error in role inference:", doc, - text "Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug"] + text "Please report this as a GHC bug: https://www.haskell.org/ghc/reportabug"] {- ************************************************************************ diff --git a/compiler/utils/Panic.hs b/compiler/utils/Panic.hs index 03f095b..4f0f3b1 100644 --- a/compiler/utils/Panic.hs +++ b/compiler/utils/Panic.hs @@ -168,7 +168,7 @@ showGhcException exception showString "panic! (the 'impossible' happened)\n" . showString (" (GHC version " ++ cProjectVersion ++ " for " ++ TargetPlatform_NAME ++ "):\n\t") . s . showString "\n\n" - . showString "Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug\n" + . showString "Please report this as a GHC bug: https://www.haskell.org/ghc/reportabug\n" throwGhcException :: GhcException -> a diff --git a/docs/users_guide/ghci.rst b/docs/users_guide/ghci.rst index 49a96ca..f468e80 100644 --- a/docs/users_guide/ghci.rst +++ b/docs/users_guide/ghci.rst @@ -37,7 +37,7 @@ command ``ghci``: .. code-block:: none $ ghci - GHCi, version 8.y.z: http://www.haskell.org/ghc/ :? for help + GHCi, version 8.y.z: https://www.haskell.org/ghc/ :? for help Prelude> There may be a short pause while GHCi loads the prelude and standard @@ -2052,7 +2052,7 @@ by using the :ghc-flag:`-package ⟨pkg⟩` flag: .. code-block:: none $ ghci -package readline - GHCi, version 8.y.z: http://www.haskell.org/ghc/ :? for help + GHCi, version 8.y.z: https://www.haskell.org/ghc/ :? for help Loading package base ... linking ... done. Loading package readline-1.0 ... linking ... done. Prelude> diff --git a/ghc/GHCi/UI.hs b/ghc/GHCi/UI.hs index ae8ba02..13275f8 100644 --- a/ghc/GHCi/UI.hs +++ b/ghc/GHCi/UI.hs @@ -162,7 +162,7 @@ defaultGhciSettings = ghciWelcomeMsg :: String ghciWelcomeMsg = "GHCi, version " ++ cProjectVersion ++ - ": http://www.haskell.org/ghc/ :? for help" + ": https://www.haskell.org/ghc/ :? for help" ghciCommands :: [Command] ghciCommands = map mkCmd [ diff --git a/rts/RtsMessages.c b/rts/RtsMessages.c index 053805e..a90962e 100644 --- a/rts/RtsMessages.c +++ b/rts/RtsMessages.c @@ -172,7 +172,7 @@ rtsFatalInternalErrorFn(const char *s, va_list ap) #endif fprintf(stderr, "\n"); fprintf(stderr, " (GHC version %s for %s)\n", ProjectVersion, xstr(HostPlatform_TYPE)); - fprintf(stderr, " Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug\n"); + fprintf(stderr, " Please report this as a GHC bug: https://www.haskell.org/ghc/reportabug\n"); fflush(stderr); } #if defined(mingw32_HOST_OS) _______________________________________________ ghc-commits mailing list ghc-commits(a)haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-commits

4 5

Re: Better perf
by Sebastian Graf 14 Dec '18

14 Dec '18

Hey, when going through Simon-nofib-notes, I stumbled over this thread from March 2017, when I hadn't yet subscribed to this list: https://mail.haskell.org/pipermail/ghc-devs/2017-March/013887.html. Joachim and Simon were trying to pin-point seemingly random regressions and improvements of ~5% to `binary-trees`. It's hard to say in retrospect, but I suspect this is the same effect I experienced in #15333 and I'm about to fix in #15999, e.g. that small changes to allocations lead to big, uncorrelated jumps in runtime performance due to GC. Just wanted to record this here for posterity. Cheers Sebastian Hi, > > Am Dienstag, den 07.03.2017, 22:55 +0000 schrieb Simon Peyton Jones via > ghc-devs: > >* > But: binary-trees runtime increases by 5%. > *> >* David: might you look to see if there is any obvious reason for this > *>* regression? We could just accept it, but it's always good to know > *>* why, and to document it. > * > Turns out that my commit > Add rule mapFB c (λx.x) = c > fixed that regression:https://perf.haskell.org/ghc/#revision/2fa44217c1d9722227297eefb… > > Maybe there is just a performance cliff there, and these jumps don’t > really mean anything. > > Greetings, > Joachim > >

1 0

Post-spec optimisation, wen and where
by Gabor Greif 13 Dec '18

13 Dec '18

Hi devs, I am wondering where the optimisation (e.g. simplified) of specialised dictionaries is taking place. In my case -ddump-spec shows unoptimised, but -ddump-simpl-iterations shows already optimised dictionaries (float-out already happened). I searched yesterday, but to no avail. Thanks, Gabor

2 2

Re: are ghc commits only getting make fast test'd on OSX?
by Carter Schonwald 10 Dec '18

10 Dec '18

yeah, this turned out to be the dwarf issue i think, On Fri, Dec 7, 2018 at 10:05 PM Ben Gamari <bgamari(a)gmail.com> wrote: > Sorry for the latency, I'm currently working through a few weeks of > email backlog. > > > Carter Schonwald <carter.schonwald(a)gmail.com> writes: > > > thats the only explanation of why i see soooo many test suite failues of > a > > GHC RELEASE when i do make test ... > > > It's hard to comment without knowing more about what specific failures > you are seeing. > > > why do we not have a full ./validate run on each tier one platform as > part > > of some official release check list? > > > We do. All of the Tier 1 platforms have go through full validation. You > can see this yourself by looking at .circleci/config.yml. > > > DO WE HAVE a checklist for releases? if not, we should, this shouldn't be > > happening > > Yes, we do. It is here [1]. > > Cheers, > > - Ben > > > [1] https://ghc.haskell.org/trac/ghc/wiki/MakingReleases >

1 0

Understanding bind in template haskell
by Yotam Ohad 10 Dec '18

10 Dec '18

Hi, In the function DsMeta.repE there is a format being repeated: For example in: repE e@(ExplicitTuple _ es boxed) | not (all tupArgPresent es) = notHandled "Tuple sections" (ppr e) | isBoxed boxed = do { xs <- repLEs [e | (dL->L _ (Present _ e)) <- es] ; repTup xs } | otherwise = do { xs <- repLEs [e | (dL->L _ (Present _ e)) <- es] ; repUnboxedTup xs } There is `(dL->L _ (Present _ e)) <- es`. I don't understand how this type checks correctly. If I'll try to do data Foo a = Foo a runQ [| Foo b <- Foo 1 |] in ghciI get an error. What is the difference? Yotam

2 1

Re: nofib output difference
by Andreas Klebinger 08 Dec '18

08 Dec '18

I fear that one is my fault. This should fix it: https://phabricator.haskell.org/D5426 I did not want to add a large binary file to the repo so instead compress generated the out file during boot. Which used to work well on my box. However make boot also creates the dependency files that guarantee the proper build order. Turns out sometimes we end up trying to build the compress executable before building the dependency file, so the build fails. I've just gave in to storing the output file in the repo now.

1 0

[ANNOUNCE] GHC 8.6.3 is now available
by Ben Gamari 07 Dec '18

07 Dec '18

Hello everyone, The GHC team is very happy to announce the availability of GHC 8.6.3, 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.3 The 8.6 release fixes several regressions present in 8.6.2 including: - A code generation bug resulting in segmentations faults in some programs (#15892) - Darwin binary distributions are now correctly built against an in-tree GMP (#15404) - Three bugs leading to linker failures on Windows (#15105, #15894, #15934) - A bug leading to programs with deep stacks crashing when run with retainer profiling enabled (#14758) - A bug resulting in potential heap corruption during stable name allocation (#15906) - Plugins are now loaded during GHCi sessions (#15633) 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. Happy compiling! Cheers, - Ben [1] https://ghc.haskell.org/trac/ghc/query?status=closed&milestone=8.6.3&col=id…

1 0

nofib output difference
by Joachim Breitner 07 Dec '18

07 Dec '18

Hi, currently, perf.haskell.org has stopped because recent commits fail to build with: expected stdout not matched by reality --- fft2.stdout7 2018-11-28 12:00:24.126015465 -0500 +++ /tmp/runtest6392.1 2018-11-28 12:59:59.329423367 -0500 @@ -1,3 +1,3 @@ -result1 = 2.59635799135966e-12 -result2 = 2.59635799135966e-12 -result3 = 4.8279900966008427e-8 +result1 = 2.649891777856828e-12 +result2 = 2.649891777856828e-12 +result3 = 4.830900479646516e-8 make[2]: *** [../../mk/target.mk:102: runtests] Error 1 do others observe this as well? This is worrying, because there has been no change to nofib since it last worked. Can we add a check of the functional correctness of the nofib programs to the CI somehow? Cheers, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

3 4