Ben Gamari authored 5 years ago and Marge Bot committed 5 years ago

This broke the Windows build.

Ben Gamari authored 5 years ago and Marge Bot committed 5 years ago

Should finally fix #17255.

Ömer Sinan Ağacan authored 5 years ago and Marge Bot committed 5 years ago

As reported in #8173 in some environments package lists can get quite
long, so we use more efficient ordNub instead of nub on package lists.

vdukhovni authored 5 years ago and Marge Bot committed 5 years ago

If using a pthread instead of a timer signal is more reliable, and
has no known drawbacks, then FreeBSD is also capable of supporting
this mode of operation (tested on FreeBSD 12 with GHC 8.8.1, but
no reason why it would not also work on FreeBSD 11 or GHC 8.6).

Proposed by Kevin Zhang in:

    https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=241849

Ben Gamari authored 5 years ago and Marge Bot committed 5 years ago

`GHC.Prim.seq` previously had the rather plain type:

    seq :: forall a b. a -> b -> b

However, it also had a special typing rule to applications
where `b` is not of kind `Type`.

Issue #17440 noted that levity polymorphism allows us to rather give
it the more precise type:

    seq :: forall (r :: RuntimeRep) a (b :: TYPE r). a -> b -> b

This allows us to remove the special typing rule that we previously
required to allow applications on unlifted arguments. T9404 contains a
non-Type application of `seq` which should verify that this works as
expected.

Closes #17440.

Ben Gamari authored 5 years ago and Marge Bot committed 5 years ago

The need for this note vanished in
eae703aa.

Alex D authored 5 years ago and Marge Bot committed 5 years ago

Metric Decrease:
    T14683

Ben Gamari authored 5 years ago and Marge Bot committed 5 years ago

It is typical for $TMP to be a small tmpfson Linux. This test will fail
in such cases since we must create a file larger than the filesystem.
See #17459.

The previous commit hasn't made it to master yet.

Adopts the language suggested by @JakobBruenker.

I previously increased the size of the acceptance window from 2% to 5%
but this still isn't enough. Regardless, measuring bytes allocated
should be sufficient to catch any regressions.

Bumps haddock submodule.

We ran it against the .git directory despite the fact that the linter
wants to be run against the repository.

This statistic is rather unstable. Hopefully fixes #17475.

This is an attempt to mitigate #17480 by ensuring that a functional version of
the process library is available before attempting the build.

Metric Increase:
    T4801

Haskeline now depends upon exceptions. See #16752.

Ömer Sinan Ağacan authored 5 years ago and Marge Bot committed 5 years ago

HscRecomp users only need the ModLocation of the module being compiled,
so only pass that to users instead of the entire ModSummary

Metric Decrease:
    T4801

Ryan Scott authored 5 years ago and Marge Bot committed 5 years ago

Issue #17461 was occurring because the `Outputable` instance for
standalone kind signatures was simply calling `ppr` on the name in
the kind signature, which does not add parentheses to infix names.
The solution is simple: use `pprPrefixOcc` instead.

Fixes #17461.

Ben Gamari authored 5 years ago and Marge Bot committed 5 years ago

As noted in #17458, QuantifiedConstraints and UndecideableInstances
could previously be used to write programs which can loop at runtime.
This was fixed in !1870.

Alp Mestanogullari authored 5 years ago and Marge Bot committed 5 years ago

By only using 'export' from within bash commands.

Ben Gamari authored 5 years ago and Marge Bot committed 5 years ago

Previously an import cycle between Type and TyCoRep meant that several
functions in TyCoRep ended up SOURCE import coreView. This is quite
unfortunate as coreView is intended to be fused into a larger pattern
match and not incur an extra call.

Fix this with a bit of restructuring:

 * Move the functions in `TyCoRep` which depend upon things in `Type`
   into `Type`
 * Fold contents of `Kind` into `Type` and turn `Kind` into a simple
   wrapper re-exporting kind-ish things from `Type`
 * Clean up the redundant imports that popped up as a result

Closes #17441.

Metric Decrease:
    T4334

Ömer Sinan Ağacan authored 5 years ago and Marge Bot committed 5 years ago

[ci skip]

Alp Mestanogullari authored 5 years ago and Ben Gamari committed 5 years ago

We instead want to collect the runtime stats (with collect_stats, instead of
collect_compiler_stats).

This should fix a number of perf tests failures we have been seeing, where
we suddenly started measuring metrics we didn't intend to measure, which
tend to fall outside of the acceptance window.

Metric Decrease:
    lazy-bs-alloc
    T3586

Metric Increase:
    space_leak_001
    T4801
    T5835
    T12791

Alp Mestanogullari authored 5 years ago and Ben Gamari committed 5 years ago

The corresponding commit might introduce a regression on a perf test, in which
case we certainly want to record it. The testsuite might also fail because
of a test unrelated to performance, in which case we want to record that the
perf test results were good.

Either way, we likely want to record them under all circumstances but
we don't without this patch.

Metric Decrease:
    T3586

Metric Increase:
    lazy-bs-alloc

Alp Mestanogullari authored 5 years ago and Ben Gamari committed 5 years ago

This addresses #17456 and also fixes the --metrics-file argument that Hadrian
passes to the testsuite driver.

Previously we would call check_stats to check the runtime metrics even
if the test definition hadn't requested it. This would result in an
error since the .stats file doesn't exist.

As suggested in #17387; this helps reduce the variance in our residency
sampling.

Metric Increase:
    T10370
    T3586
    lazy-bs-alloc

Metric Decrease 'compile_time/peak_megabytes_allocated':
    T1969

Metric Decrease 'runtime/bytes allocated':
    space_leak_001

Metric Increase 'compile_time/bytes allocated':
    T1969

Metric Increase 'runtime/peak_megabytes_allocated':
    space_leak_001

Metric Decrease:
    T3064
    T9675

Richard Eisenberg authored 5 years ago and Marge Bot committed 5 years ago

Previously, we checked all imported type family equations
for injectivity. This is very silly. Now, we check only
for conflicts.

Before I could even imagine doing the fix, I needed to untangle
several functions that were (in my opinion) overly complicated.
It's still not quite as perfect as I'd like, but it's good enough
for now.

Test case: typecheck/should_compile/T17405