GitLab

Summary:
Sometimes we need to be able to mass accept changes that are platform
specific and that can't be normalized away using our string formatters.

e.g. differences in I/O manager errors or behaviors. This allows one
to do so easier than before and less error prone.

I have updated the docs and made it clear this should only be used
when a normalizer won't work:

https://ghc.haskell.org/trac/ghc/wiki/Building/RunningTests/Updating

Test Plan: Manually tested while working on new I/O manager

Reviewers: bgamari

Subscribers: thomie, carter

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

Summary:
This shims out fopen and sopen so that they use modern APIs under the hood
along with namespaced paths.

This lifts the MAX_PATH restrictions from Haskell programs and makes the new
limit ~32k.

There are only some slight caveats that have been documented.

Some utilities have not been upgraded such as lndir, since all these things are
different cabal packages I have been forced to copy the source in different places
which is less than ideal. But it's the only way to keep sdist working.

Test Plan: ./validate

Reviewers: hvr, bgamari, erikd, simonmar

Reviewed By: bgamari

Subscribers: rwbarton, thomie, carter

GHC Trac Issues: #10822

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

Reviewers: bgamari, erikd, simonmar

Reviewed By: bgamari

Subscribers: thomie, carter

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

[skip ci]

Now we use the images from the ‘ghcci’ account on docker hub.

The sinking pass often gets rid of unnecessary registers
registers/assignements exposing more opportunities for CBE, so this
commit adds a second round of CBE after the sinking pass and should
fix #12915 (and some examples in #14226).

Nofib results:
* Binary size:         0.9% reduction on average
* Compile allocations: 0.7% increase on average
* Runtime:             noisy, two separate runs of nofib showed a tiny
                       reduction on average, (~0.2-0.3%), but I think
                       this is mostly noise
* Compile time:        very noisy, but generally within +/- 0.5% (one
                       run faster, one slower)

One interesting part of this change is that running CBE invalidates
results of proc-point analysis. But instead of re-doing the whole
analysis, we can use the map that CBE creates for replacing/comparing
block labels (maps a redundant label to a useful one) to update the
results of proc-point analysis. This lowers the overhead compared to the
previous experiment in #12915.
Signed-off-by: Michal Terepeta <michal.terepeta@gmail.com>

Test Plan: ./validate

Reviewers: bgamari, simonmar

Reviewed By: simonmar

Subscribers: rwbarton, thomie, carter

GHC Trac Issues: #12915, #14226

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

Test Plan: Try running configure on Windows with msys and mingw
toolchains

Reviewers: Phyx, hvr

Reviewed By: Phyx

Subscribers: rwbarton, thomie, erikd, carter

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

Only half of the test files were checked in for T13938.
This commit adds the missing half.

Trac #13900 showed that when we have a join point that
has a RULE, we must push the continuation into the RHS
of the RULE.

See Note [Rules and unfolding for join points]

It's hard to tickle this bug, so I have not added a regression test.

Minor refactor and comments, following Ryan's excellent DeriveAnyClass
bug (Trac #14932)

I took 10 minute to fix this potential performance hole
(Trac #14263)

There are no actual bug reports against it, so no regression
test.

This patch, authored by alexvieth and reviewed at D4451,
makes performance improvements by critically optimizing parts
of the flattener.

Summary:
T3064, T5321FD, T5321Fun, T9872a, T9872b, T9872c all pass.
T9872a and T9872c show improvements beyond the -5% threshold.
T9872d fails at 10.9% increased allocations.

This changes a key invariant of the flattener. Previously,
flattening a type meant flattening its kind as well. But now,
flattening is always homogeneous -- that is, the kind of the
flattened type is the same as the kind of the input type.
This is achieved by various wizardry in the TcFlatten.flatten_many
function, as described in Note [flatten_many].

There are several knock-on effects, including some refactoring
in the canonicalizer to take proper advantage of the flattener's
changed behavior. In particular, the tyvar case of can_eq_nc' no
longer needs to take casts into account.

Another effect is that flattening a tyconapp might change it
into a casted tyconapp. This might happen if the result kind
of the tycon contains a variable, and that variable changes
during flattening. Because the flattener is homogeneous, it tacks
on a cast to keep the tyconapp kind the same. However, this
is problematic when flattening CFunEqCans, which need to have
an uncasted tyconapp on the LHS and must remain homogeneous.
The solution is a more involved canCFunEqCan, described in
Note [canCFunEqCan].

This patch fixes #13643 (as tested in typecheck/should_compile/T13643)
and the panic in typecheck/should_compile/T13822 (as reported in #14024).
Actually, there were two bugs in T13822: the first was just some
incorrect logic in tryFill (part of the unflattener) -- also fixed
in this patch -- and the other was the main bug fixed in this ticket.

The changes in this patch exposed a long-standing flaw in OptCoercion,
in that breaking apart an AppCo sometimes has unexpected effects on
kinds. See new Note [EtaAppCo] in OptCoercion, which explains the
problem and fix.

Also here is a reversion of the major change in
09bf135a, affecting ctEvCoercion.
It turns out that making the flattener homogeneous changes the
invariants on the algorithm, making the change in that patch
no longer necessary.

This patch also fixes:
  #14038 (dependent/should_compile/T14038)
  #13910 (dependent/should_compile/T13910)
  #13938 (dependent/should_compile/T13938)
  #14441 (typecheck/should_compile/T14441)
  #14556 (dependent/should_compile/T14556)
  #14720 (dependent/should_compile/T14720)
  #14749 (typecheck/should_compile/T14749)

Sadly, this patch negatively affects performance of type-family-
heavy code. The following patch fixes these performance degradations.
However, the performance fixes are somewhat invasive and so I've
kept them as a separate patch, labeling this one as [skip ci] so
that validation doesn't fail on the performance cases.

Commit 94f02547
added some pragmas that allow GCC to compile GHC, but stop
macOS's clang. This adds another counter-pragma to halp
clang lumber along, too.

Fixes #14977.

StgLam can't have empty arguments. Reflect this in types. An assertion
can now be deleted.

Reviewers: bgamari

Reviewed By: bgamari

Subscribers: rwbarton, thomie, carter

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

There should be no change in the output of the '+RTS -s' (summary)
report, or
the 'RTS -t' (one-line) report.

All data shown in the summary report is now shown in the machine
readable
report.

All data in RTSStats is now shown in the machine readable report.

init times are added to RTSStats and added to GHC.Stats.

Example of the new output:
```
 [("bytes allocated", "375016384")
 ,("num_GCs", "113")
 ,("average_bytes_used", "148348")
 ,("max_bytes_used", "206552")
 ,("num_byte_usage_samples", "2")
 ,("peak_megabytes_allocated", "6")
 ,("init_cpu_seconds", "0.001642")
 ,("init_wall_seconds", "0.001027")
 ,("mut_cpu_seconds", "3.020166")
 ,("mut_wall_seconds", "0.757244")
 ,("GC_cpu_seconds", "0.037750")
 ,("GC_wall_seconds", "0.009569")
 ,("exit_cpu_seconds", "0.000890")
 ,("exit_wall_seconds", "0.002551")
 ,("total_cpu_seconds", "3.060452")
 ,("total_wall_seconds", "0.770395")
 ,("major_gcs", "2")
 ,("allocated_bytes", "375016384")
 ,("max_live_bytes", "206552")
 ,("max_large_objects_bytes", "159344")
 ,("max_compact_bytes", "0")
 ,("max_slop_bytes", "59688")
 ,("max_mem_in_use_bytes", "6291456")
 ,("cumulative_live_bytes", "296696")
 ,("copied_bytes", "541024")
 ,("par_copied_bytes", "493976")
 ,("cumulative_par_max_copied_bytes", "104104")
 ,("cumulative_par_balanced_copied_bytes", "274456")
 ,("fragmentation_bytes", "2112")
 ,("alloc_rate", "124170795")
 ,("productivity_cpu_percent", "0.986838")
 ,("productivity_wall_percent", "0.982935")
 ,("bound_task_count", "1")
 ,("sparks_count", "5836258")
 ,("sparks_converted", "237")
 ,("sparks_overflowed", "1990408")
 ,("sparks_dud ", "0")
 ,("sparks_gcd", "3455553")
 ,("sparks_fizzled", "390060")
 ,("work_balance", "0.555606")
 ,("n_capabilities", "4")
 ,("task_count", "10")
 ,("peak_worker_count", "9")
 ,("worker_count", "9")
 ,("gc_alloc_block_sync_spin", "162")
 ,("gc_alloc_block_sync_yield", "0")
 ,("gc_alloc_block_sync_spin", "162")
 ,("gc_spin_spin", "18840855")
 ,("gc_spin_yield", "10355")
 ,("mut_spin_spin", "70331392")
 ,("mut_spin_yield", "61700")
 ,("waitForGcThreads_spin", "241")
 ,("waitForGcThreads_yield", "2797")
 ,("whitehole_gc_spin", "0")
 ,("whitehole_lockClosure_spin", "0")
 ,("whitehole_lockClosure_yield", "0")
 ,("whitehole_executeMessage_spin", "0")
 ,("whitehole_threadPaused_spin", "0")
 ,("any_work", "1667")
 ,("no_work", "1662")
 ,("scav_find_work", "1026")
 ,("gen_0_collections", "111")
 ,("gen_0_par_collections", "111")
 ,("gen_0_cpu_seconds", "0.036126")
 ,("gen_0_wall_seconds", "0.036126")
 ,("gen_0_max_pause_seconds", "0.036126")
 ,("gen_0_avg_pause_seconds", "0.000081")
 ,("gen_0_sync_spin", "21")
 ,("gen_0_sync_yield", "0")
 ,("gen_1_collections", "2")
 ,("gen_1_par_collections", "1")
 ,("gen_1_cpu_seconds", "0.001624")
 ,("gen_1_wall_seconds", "0.001624")
 ,("gen_1_max_pause_seconds", "0.001624")
 ,("gen_1_avg_pause_seconds", "0.000272")
 ,("gen_1_sync_spin", "3")
 ,("gen_1_sync_yield", "0")
 ]
```

Test Plan: Ensure that one-line and summary reports are unchanged.

Reviewers: erikd, simonmar, hvr

Subscribers: duog, carter, thomie, rwbarton

GHC Trac Issues: #14660

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

Reviewers: bgamari, simonmar

Reviewed By: bgamari

Subscribers: dfeuer, rwbarton, thomie, carter

GHC Trac Issues: #4442

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

This flag reports a summary of the inlining decision for identifiers
prefixed by the flag's argument.

For example, `-dinline-check foo` will report why definitions whose
prefix is `foo` are inlined or not.

Previously the only way to get this information was to pass a
combination of `-dverbose-core2core` and `-ddump-inlinings`.

This combination led to a log of 12 million lines in a module of about
200 lines I recently had to apply it to. This flag provides a much more
direct way to find the occurence you care about.

Reviewers: osa1, dfeuer, bgamari

Reviewed By: bgamari

Subscribers: rwbarton, thomie, carter

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

Test Plan: `make test TEST=T14925`

Reviewers: hvr, dfeuer

Reviewed By: dfeuer

Subscribers: rwbarton, thomie, carter

GHC Trac Issues: #14925

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

LLVM, like GHC, processes flags in the order that they appear.
Consequently, we need to ensure the user-provided flags appear last so
they can override flags produced by GHC. See #14821.

Test Plan: `ghc -O2 -optlo-O2 -v3 $FILE` and ensure that `opt` and `llc`
are invoked with `-O2`.

Subscribers: rwbarton, thomie, carter

GHC Trac Issues: #14821

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

Namely class methods, default signatures and pattern synonyms.

When scoped type variables occur inside class default methods,
default signatures and pattern synonyms, avoid re-create explicit
type variables when represent the type signatures.

This patch should fix Trac#14885.
Signed-off-by: HE, Tao <sighingnow@gmail.com>

Test Plan: make test TEST="T14885a T14885b T14885c"

Reviewers: goldfire, bgamari, simonpj, RyanGlScott

Reviewed By: simonpj, RyanGlScott

Subscribers: rwbarton, thomie, carter

GHC Trac Issues: #14885

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

-g1 removes block information, but it turns out that procs can
refer to block information through parents.
Note [Splitting DebugBlocks] explains the parentage relationship.

Test Plan:
* ./validate
* added a new test

Reviewers: bgamari, simonmar

Reviewed By: bgamari

Subscribers: rwbarton, thomie, carter

GHC Trac Issues: #14894

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

Manually-written instances and standalone-derived instances
have the benefit of having the `checkValidInstHead` function run over
them, which catches manual instances of built-in types like `(~)` and
`Coercible`. However, instances generated from `deriving` clauses
weren't being passed through `checkValidInstHead`, leading to
confusing results as in #14916.

`checkValidInstHead` also has additional validity checks for language
extensions like `FlexibleInstances` and `MultiParamTypeClasses`. Up
until now, GHC has never required these language extensions for
`deriving` clause, so to avoid unnecessary breakage, I opted to
suppress these language extension checks for `deriving` clauses, just
like we currently suppress them for `SPECIALIZE instance` pragmas.

Test Plan: make test TEST=T14916

Reviewers: goldfire, bgamari

Reviewed By: bgamari

Subscribers: rwbarton, thomie, carter

GHC Trac Issues: #14916

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

Test Plan: Validate

Reviewers: alpmestan

Reviewed By: alpmestan

Subscribers: alpmestan, leftaroundabout, rwbarton, thomie, carter

GHC Trac Issues: #14925

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

While investigating #14947, I noticed that the `barf`ed
error message in `push()` doesn't print out the closure type that
causes it to crash. Let's do so.

Reviewers: bgamari, erikd, simonmar

Reviewed By: bgamari

Subscribers: alexbiehl, rwbarton, thomie, carter

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

Accroding to
https://git.haskell.org/ghc.git/commitdiff/49672659113371c3bee691e6d913d
f8e6f60a1d8,
`-Wredundant-constraints` is no longer turn on by default.

Reviewers: bgamari

Reviewed By: bgamari

Subscribers: rwbarton, thomie, carter

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

Test Plan: new test overloadedrecflds/should_fail/T14953

Reviewers: mpickering, simonpj, bgamari

Reviewed By: bgamari

Subscribers: rwbarton, thomie, carter

GHC Trac Issues: #14953

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

With a large heap it's possible to build up a lot of finalizers
between GCs.  We've observed GC spending up to 50% of its time running
finalizers.  But there's no reason we have to run finalizers during
GC, and especially no reason we have to block *all* the mutator
threads while *one* GC thread runs finalizers one by one.

I thought about a bunch of alternative ways to handle this, which are
documented along with runSomeFinalizers() in Weak.c.  The approach I
settled on is to have a capability run finalizers if it is idle.  So
running finalizers is like a low-priority background thread. This
requires some minor scheduler changes, but not much.  In the future we
might be able to move more GC work into here (I have my eye on freeing
large blocks, for example).

Test Plan:
* validate
* tested on our system and saw reductions in GC pauses of 40-50%.

Reviewers: bgamari, niteria, osa1, erikd

Reviewed By: bgamari, osa1

Subscribers: rwbarton, thomie, carter

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

Test Plan: ci

Reviewers: osa1, bgamari, erikd

Reviewed By: osa1

Subscribers: rwbarton, thomie, carter

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