GitLab

Summary:
This is a fixup of https://phabricator.haskell.org/D233

The only difference is in findTFiles (first commit), which
previously broke Windows runner; now I translated literally
instead attempting to improve it, and checked it works.

Test Plan:
I used validate under 2,3 on Linux and under 2 on msys2.
On Windows I've seen a large number of failures, but they don't
seem to be connected with the patch.

Reviewers: hvr, simonmar, thomie, austin

Reviewed By: austin

Subscribers: thomie, carter, ezyang, simonmar

Differential Revision: https://phabricator.haskell.org/D310

GHC Trac Issues: #9184

which I just put it in comments. Thanks Yuras for noticing, and sorry
for the noise.

to include at least what’s observed on ghc-speed and my laptop, and
hopefully also Harbormaster.

including T9675 itself. Maybe its memory behaviour is too spiky for
max_bytes_used and peak_megabytes_allocated to be used sensibly at all.

otherwise this can retain large lazy calculations. This fixed one space
leak pointed out in #9675.

although I obtained them originally from a clean validate tree on my
laptop, they did not match what I found on the build bot host.

so that whoever improves the situation can feel good about it.

This reverts commit 084d241b.

This is a possible culprit of Windows breakage reported at ghc-devs.

Summary:
Most of the changes is adaptation of old Python 2 only code.
My priority was not breaking Python 2, and so I avoided bigger
changes to the driver. In particular, under Python 3 the output
is a str and buffering cannot be disabled.

To test, define PYTHON=python3 in testsuite/mk/boilerplate.mk.

Thanks to aspidites <emarshall85@gmail.com> who provided the initial patch.

Test Plan: validate under 2 and 3

Reviewers: hvr, simonmar, thomie, austin

Reviewed By: thomie, austin

Subscribers: aspidites, thomie, simonmar, ezyang, carter

Differential Revision: https://phabricator.haskell.org/D233

GHC Trac Issues: #9184

T4801 is deactived for now because it's currently too volatile
and causes too much noise in Phabricator's CI

Reviewed By: austin

Differential Revision: https://phabricator.haskell.org/D230

In `base`, the instances

  instance Show ()
  instance Show Bool
  instance Show Ordering
  instance Show a => Show (Maybe a)

where defined manually, even though we can leverage GHC's auto-deriver
which is perfectly capable by standalone derivation to avoid boiler-plate
code such as this.

Reviewed By: austin

Differential Revision: https://phabricator.haskell.org/D219

This exposes *only* the type-classes w/o any of their methods.
This is the very first step for implementing BPP (see #9586), which
already requires breaking up several import-cycles leading back to `Prelude`.

Ideally, importing `Prelude` should be avoided in most `base` modules,
as `Prelude` does not define any entities, but rather re-exports
existing ones.

Test Plan: validate passes

Reviewers: ekmett, austin

Reviewed By: ekmett, austin

Subscribers: simonmar, ezyang, carter

Differential Revision: https://phabricator.haskell.org/D209

GHC Trac Issues: #9586

Right now, Phab's buildbot complains about

  Unexpected failures:
    perf/compiler T1969 [stat too good] (normal)
    perf/compiler T4801 [stat not good enough] (normal)

However, on my workstation, those tests don't fail (c.f. P14).
So this commit tries to blindly tweak those numbers and see if
if Phabricator succeeds to build this code-revision...

Test Plan: Let Harbormaster build it

Reviewers: austin

Subscribers: simonmar, ezyang, carter

Differential Revision: https://phabricator.haskell.org/D210

(I obviously copy’n’pasted the wrong number.)

including some that are not failing yet, but did show a significant
change, and some that Austing changed post-AMP, but where both
harbormaster and ghcspeed reported something else. Numbers taken from
the ghcspeed machine.

Summary:
This includes pretty much all the changes needed to make `Applicative`
a superclass of `Monad` finally. There's mostly reshuffling in the
interests of avoid orphans and boot files, but luckily we can resolve
all of them, pretty much. The only catch was that
Alternative/MonadPlus also had to go into Prelude to avoid this.

As a result, we must update the hsc2hs and haddock submodules.
Signed-off-by: Austin Seipp <austin@well-typed.com>

Test Plan: Build things, they might not explode horribly.

Reviewers: hvr, simonmar

Subscribers: simonmar

Differential Revision: https://phabricator.haskell.org/D13

no individual cause indentified, but small improvements happened in
1719c420, 9d6fbcc7, 949ad67e (or it is noise...)

This reverts commit 9711f78f, as it's
causing build phailures in phabricator.

Summary:
* Adjusts performance tests
* Change ghcpkg05.stderr-mingw32 to match ghcpkg05.stderr

Test Plan: Ran 'sh validate' and observed fewer test failures afterwards

Reviewers: austin

Reviewed By: austin

Differential Revision: https://phabricator.haskell.org/D191

This is a result of one of these, or a combination
  002b7a2b * Give the worker for an INLINABLE function a suitably-phased Activation
  ca666b8b * When finding loop breakers, distinguish INLINE from INLINEABLE
  a98c9c5e * Fix a bug in CSE, for INLINE/INLNEABLE things

Some changes are quite big: for bytes_allocated we have
  T6048: 13% below expected
  T5837: 15% below expected
  T3064:  5% below expected

Of course, these might have already been close to their lower
threshold, so perhaps not all the improvement is from here.
But it is good news all the same.

* T1969 improves, perhaps because of better specialiation

* T5642 (a bizarre case) worsens, because we get lots and lots
  of specialisations of imported functions for the lots and
  lots of data types T5642 declares

This  +4% increase (from -1% before) was caused by 1fc60ea1. But that
commit did not cause any other regressions, so I’m not investigating
further.

These did not yet trigger a failure, but are more than 1% away from the
expected value. Since I now start collecting logs to investigate
deviations from the expected value, it makes sense to reset them. This
way we know that every significat deviation was caused since this
commit.

I only updated bytes_allocated numbers, as these are (mostly)
deterministic. Other depend, AFAIK, on sampling timing, so I did not
bother.

This was likely caused by 5e7406d9, which fixed #9233.

I started monitoring perfomance on a per-commit base. These seem to be
off for a while now. Adjusting them, and from now I hope I can keep
closer tabs on them.

Summary:
This should fix the Harbormaster builds; the bounds are just a little too narrow.
Signed-off-by: Austin Seipp <austin@well-typed.com>

Test Plan: Harbormaster should build successfully.

Reviewers: simonmar

Subscribers: phaskell, simonmar, relrod, carter

Projects: #ghc

Differential Revision: https://phabricator.haskell.org/D65

Some numbers have decreased but the haddock numbers have generally
increased noticeable again (see also last update in 970e5d99)

This updates all numbers I noticed in the "fast" test-mode, *except* for
the T9203 test-case on 32bit, which needs more investigation before
bumping due to its significant increase:

  bytes allocated value is too high:
      Expected    bytes allocated: 50000000 +/-5%
      Lower bound bytes allocated: 47500000
      Upper bound bytes allocated: 52500000
      Actual      bytes allocated: 85093548
  *** unexpected failure for T9203(normal)

I'm not sure why this has increased, but it seems small

Many of these have never been initialised, I think.  They
were simply guesses from the 64-bit version.