Ben Gamari authored 6 years ago and Ben Gamari committed 6 years ago

Summary: Currently broken.

Test Plan: Validate

Subscribers: rwbarton, thomie, carter

GHC Trac Issues: #15186

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

Just look for the rule firing that we want to see instead of matching on
the entire dump.

Fixes #15088.

This patch implements the API proposed as pull request #108 for plugin
authors to influence the recompilation checker.

It adds a new field to a plugin which computes a `FingerPrint`. This is
recorded in interface files and if it changes then we recompile the
module. There are also helper functions such as `purePlugin` and
`impurePlugin` for constructing plugins which have simple recompilation
semantics but in general, an author can compute a hash as they wish.

Fixes #12567 and #7414

https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/002
2-plugin-recompilation.rst

Reviewers: bgamari, ggreif

Reviewed By: bgamari

Subscribers: rwbarton, thomie, carter

GHC Trac Issues: #7414, #12567

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

Matthías Páll Gissurarson authored 6 years ago and Ben Gamari committed 6 years ago

I've changed the name from `Valid substitutions` to `Valid hole fits`,
since "substitution" already has a well defined meaning within the
theory. As part of this change, the flags and output is reanamed, with
substitution turning into hole-fit in most cases. "hole fit" was already
used internally in the code, it's clear and shouldn't cause any
confusion.

In this update, I've also reworked how we manage side-effects in the
hole we are considering.

This allows us to consider local bindings such as where clauses and
arguments to functions, suggesting e.g. `a` for `head (x:xs) where head
:: [a] -> a`.

It also allows us to find suggestions such as `maximum` for holes of
type `Ord a => a -> [a]`, and `max` when looking for a match for the
hole in `g = foldl1 _`, where `g :: Ord a => [a] -> a`.

We also show much improved output for refinement hole fits, and
fixes #14990. We now show the correct type of the function, but we also
now show what the arguments to the function should be e.g. `foldl1 (_ ::
Integer -> Integer -> Integer)` when looking for `[Integer] -> Integer`.

I've moved the bulk of the code from `TcErrors.hs` to a new file,
`TcHoleErrors.hs`, since it was getting too big to not live on it's own.

This addresses the considerations raised in #14969, and takes proper
care to set the `tcLevel` of the variables to the right level before
passing it to the simplifier.

We now also zonk the suggestions properly, which improves the output of
the refinement hole fits considerably.

This also filters out suggestions from the `GHC.Err` module, since even
though `error` and `undefined` are indeed valid hole fits, they are
"trivial", and almost never useful to the user.

We now find the hole fits using the proper manner, namely by solving
nested implications. This entails that the givens are passed along using
the implications the hole was nested in, which in turn should mean that
there will be fewer weird bugs in the typed holes.

I've also added a new sorting method (as suggested by SPJ) and sort by
the size of the types needed to turn the hole fits into the type of the
hole. This gives a reasonable approximation to relevance, and is much
faster than the subsumption check. I've also added a flag to toggle
whether to use this new sorting algorithm (as is done by default) or the
subsumption algorithm. This fixes #14969

I've also added documentation for these new flags and update the
documentation according to the new output.

Reviewers: bgamari, goldfire

Reviewed By: bgamari

Subscribers: simonpj, rwbarton, thomie, carter

GHC Trac Issues: #14969, #14990, #10946

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

This ensures that the deferred type error can be emitted correctly.

For `main` function in `Main` module, we have

    :Main.main = GHC.TopHandler.runMainIO main

When the type of `main` is not `IO t` and the
`-fdefer-type-errors` is enabled, the `ev_binds`
of `main` function will contain deferred type
errors.

Previously, the `ev_binds` are bound to `runMainIO main`,
rather than `main`, the type error exception at runtime
cannot be handled properly. See Trac #13838.

This patch fix that.

Test Plan: make test TEST="T13838"

Reviewers: bgamari

Reviewed By: bgamari

Subscribers: rwbarton, thomie, carter

GHC Trac Issues: #13838

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

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

Simon PJ recently fixed the problem behind this failure
so we can now expect this test to pass in all ways again.

The fixes got introduced in the following commits:
  86bba7d5
  d191db48

Test Plan: T14732 (profasm way)

Reviewers: bgamari, RyanGlScott, simonpj

Reviewed By: RyanGlScott, simonpj

Subscribers: simonpj, RyanGlScott, rwbarton, thomie, carter

GHC Trac Issues: #15163

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

Namely in T13719 and T13701.

Summary:
Another round and attempt at getting these down to 0.

We really should re-enable the CI and not wait for those cloud based ones.

I've disabled the backpack tests on windows as they are too broad, they test
as much the shell as they do the compiler.

The perf tests have been too long to track down. but the numbers are horrible
but I don't see them getting fixed so just have to accept them.

T9293 has new windows specific output because a Dyn way only flag was added.
This will of course not work on non-Dyn way builds.

Test Plan: ./validate

Reviewers: bgamari, hvr, simonmar

Reviewed By: bgamari

Subscribers: rwbarton, thomie, carter

GHC Trac Issues: #15107

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

This data type witnesses the lifting of a monoid into an applicative
pointwise.

This appears to have been fixed at some point between GHC 8.0 and
8.2.

Commit 433b80de fixed #14172. Let's
add a regression test to ensure that it stays fixed.

Ben Gamari authored 6 years ago and Ömer Sinan Ağacan committed 6 years ago

Test Plan: Validate

Reviewers: int-index, osa1

Reviewed By: osa1

Subscribers: rwbarton, thomie, carter

GHC Trac Issues: #15038

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

Summary:
(re-applying this patch now that D4659 is committed)

Space leaks in GHCi emerge from time to time and tend to come back again
after they get fixed. This is an attempt to limit regressions by

* adding a reliable detection for some classes of space leaks in GHCi
* turning on leak checking for all GHCi tests in the test suite, so that
  we'll notice if the leak appears again.

The idea for detecting space leaks is quite simple:

* find some data that we expect to be GC'd later, make a weak pointer to it
* when we expect the data to be dead, do a `performGC` and then check
  the status of the weak pointer.

It would be nice to apply this trick to lots of things in GHC,
e.g. ensuring that HsSyn is not retained after the desugarer, or
ensuring that CoreSyn from the previous simplifier pass is not retained.

Test Plan: validate

Reviewers: bgamari, simonpj, erikd, niteria

Subscribers: thomie, carter

GHC Trac Issues: #15111

Summary:
The way we were pretty-printing conflicting data family
instances in an error message was far from ideal:

1. If a data type had no constructors, it would print an equals sign
   with nothing to the right of it.
2. It would try to print GADTs using Haskell98 syntax.
3. It eta-reduced away some type variables from the LHS.

This patch addresses these three issues:

1. We no longer print constructors at all in this error message.
   There's really no reason to do so in the first place, since
   duplicate data family instances always conflict, regardless of
   their constructors.
2. Since we no longer print constructors, we no longer have to
   worry about whether we're using GADT or Haskell98 syntax.
3. I've put in a fix to ensure that type variables are no longer
   eta-reduced away from the LHS.

Test Plan: make test TEST=T14179

Reviewers: goldfire, bgamari

Reviewed By: bgamari

Subscribers: rwbarton, thomie, carter

GHC Trac Issues: #14179

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

Summary:
Template Haskell provides a wormhole through which you can
sneak methods that don't belong to a class into an instance for that
class, bypassing the renamer's validity checks. The solution adopted
here is to mirror the treatment for associated type family instances,
which have an additional check in the typechecker which catch
mismatched associated type families that were snuck through using
Template Haskell. I've put a similar check for class methods into
`tcMethods`.

Test Plan: make test TEST=T12387

Reviewers: bgamari, simonpj

Reviewed By: bgamari, simonpj

Subscribers: simonpj, rwbarton, thomie, carter

GHC Trac Issues: #12387

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

Sadly I can't easily determine the cause of T13701's regression since the tree
was broken.

Trac #15122 turned out to be interesting.

* Were calling dischargeFmv in three places.

* In all three cases we dealt with the Given case
  separately.

* In two of the three cases the Given code was right,
  (albeit duplicated).

* In the third case (in TcCanonical.canCFunEqCan), we had
     ; case flav of
         Given -> return () -- nothing more to do.
  which was utterly wrong.

The solution is easy: move the Given-case handling into
dischargeFmv (now reenamed dischargeFunEq), and delete it
from the call sites.

Result: less code, easier to understand (dischargeFunEq handles
all three cases, not just two out of three), and Trac #15122 is fixed.

the hot path contained a call to

    v `elemUnVarSet` (neighbors g v)

and creating the set of neighbors just to check if `v` is inside
accounted for half the allocations of the test case of #15164.

By introducing a non-allocating function `hasLoopAt` for this we shave
off half the allocations. This brings the total cost of Call Arity down
to 20% of time and 23% of allocations, according to a profiled run. Not
amazing, but still much better.

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

This reverts commit 1cdc14f9.

This is causing non-deterministic testsuite output.

This patch adds a check for type families to the instance-decl
termination check.  See Note [Type families in instance contexts]
and Trac #15172.

A Derived CFunEqCan does not "own" its FlatMetaTv (fmv), and should not
update it.  But one caller (canCFunEqCan) was failing to satisfy the
precondition to dischargeFmv, which led to a crash (Trac #15170).

I fixed this by making dischargeFmv handle Deriveds (to avoid forcing
each caller to do so separately).

NB: this does not completely fix the original #15170 bug, but I'll
explain that on the ticket.  The test case for this patch is actually
the program in comment:1.

Trac #15164 showed that it sometimes really matters to share
sub-proofs when solving constraints.  Without it, we can get
exponentialy bad behaviour.

Fortunately, it's easily solved.
Note [Shortcut try_solve_from_instance] explains.

I did some minor assocaited refactoring.

Austin Seipp authored 6 years ago and Ben Gamari committed 6 years ago

See `Note [Recompute abi-depends]` for more information.

Signed-off-by: Austin Seipp <aseipp@pobox.com>

Test Plan: `./validate`

Reviewers: bgamari, ezyang

Reviewed By: bgamari

Subscribers: tdammers, juhp, carter, alexbiehl, shlevy, cocreature,
rwbarton, thomie

GHC Trac Issues: #14381

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

Ben Gamari authored 6 years ago and Ben Gamari committed 6 years ago

unpackClosure#'s behavior and type has changed. This caused a CPP guard
in the new ghc-heap package to fail when bootstrapping with GHC 8.4.

Test Plan: Validate bootstrapping with GHC 8.4

Reviewers: RyanGlScott

Subscribers: rwbarton, thomie, carter

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

patrickdoc authored 6 years ago and Ben Gamari committed 6 years ago

This pulls parts of Joachim Breitner's ghc-heap-view library inside GHC.
The bits added are the C hooks into the RTS and a basic Haskell wrapper
to these C hooks. The main reason for these to be added to GHC proper
is that the code needs to be kept in sync with the closure types
defined by the RTS. It is expected that the version of HeapView shipped
with GHC will always work with that version of GHC and that extra
functionality can be layered on top with a library like ghc-heap-view
distributed via Hackage.

Test Plan: validate

Reviewers: simonmar, hvr, nomeata, austin, Phyx, bgamari, erikd

Reviewed By: bgamari

Subscribers: carter, patrickdoc, tmcgilchrist, rwbarton, thomie

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

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

This finally gets us to a green ./validate --slow on linux for a ghc
checkout from the beginning of this week, see

  https://circleci.com/gh/ghc/ghc/4739

This is hopefully the final (or second to final) patch to
address #14890.

Test Plan: ./validate --slow

Reviewers: bgamari, hvr, simonmar

Reviewed By: bgamari

Subscribers: rwbarton, thomie, carter

GHC Trac Issues: #14890

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

Jack Henahan authored 6 years ago and Ben Gamari committed 6 years ago

Add Foldable and Traversable instances for Data.Monoid.Alt

Signed-off-by: Jack Henahan <jhenahan@me.com>

Reviewers: hvr, bgamari

Reviewed By: bgamari

Subscribers: mpickering, rwbarton, thomie, carter

GHC Trac Issues: #15099

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

This patch is an easy fix to Trac #15144, which was caused
by accidentally unifying a representational equality in the
unflattener.  (The main code in TcInteract was always careful
not to do so, but I'd missed the test in the unflattener.)

See Note [Do not unify representational equalities]
in TcInteract

Trac #15009 showed that, for Given TyVar/TyVar equalities, we really
want to orient them with the deepest-bound skolem on the left. As it
happens, we also want to do the same for Wanteds, but for a different
reason (more likely to be touchable).  Either way, deepest wins:
see TcUnify Note [Deeper level on the left].

This observation led me to some significant changes:

* A SkolemTv already had a TcLevel, but the level wasn't really being
  used.   Now it is!

* I updated added invariant (SkolInf) to TcType
  Note [TcLevel and untouchable type variables], documenting that
  the level number of all the ic_skols should be the same as the
  ic_tclvl of the implication

* FlatSkolTvs and FlatMetaTvs previously had a dummy level-number of
  zero, which messed the scheme up.   Now they get a level number the
  same way as all other TcTyVars, instead of being a special case.

* To make sure that FlatSkolTvs and FlatMetaTvs are untouchable (which
  was previously done via their magic zero level) isTouchableMetaTyVar
  just tests for those two cases.

* TcUnify.swapOverTyVars is the crucial orientation function; see the
  new Note [TyVar/TyVar orientation].  I completely rewrote this function,
  and it's now much much easier to understand.

I ended up doing some related refactoring, of course

* I noticed that tcImplicitTKBndrsX and tcExplicitTKBndrsX were doing
  a lot of useless work in the case where there are no skolems; I
  added a fast-patch

* Elminate the un-used tcExplicitTKBndrsSig; and thereby get rid of
  the higher-order parameter to tcExpliciTKBndrsX.

* Replace TcHsType.emitTvImplication with TcUnify.checkTvConstraints,
  by analogy with TcUnify.checkConstraints.

* Inline TcUnify.buildImplication into its only call-site in
  TcUnify.checkConstraints

* TcS.buildImplication becomes TcS.CheckConstraintsTcS, with a
  simpler API

* Now that we have NoEvBindsVar we have no need of termEvidenceAllowed;
  nuke the latter, adding Note [No evidence bindings] to TcEvidence.

Happily, both of these issues appear to have been fixed in GHC 8.2.
Let's add regression tests for them to ensure that they stay fixed.

Summary:
There were a number of leaks causing previously loaded modules to be
retained after a new `:load`.  This fixes enough leaks to get the
tests to pass from D4658.

Test Plan: See new tests in D4658

Reviewers: niteria, bgamari, simonpj, erikd

Subscribers: thomie, carter

GHC Trac Issues: #15111

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

Under certain circumstances, `GeneralizedNewtypeDeriving`
can emit code which uses unboxed tuple types, but if `UnboxedTuples`
wasn't enabled, the error message that GHC gave didn't make it very
clear that it could be worked around by explicitly enabling the
extension. Easily fixed.

Test Plan: make test TEST=T15073

Reviewers: bgamari

Reviewed By: bgamari

Subscribers: simonpj, thomie, carter

GHC Trac Issues: #15073

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

Fixes #15081.

Test Plan: cd libraries/base && make test TEST="enumNumeric"

Reviewers: hvr, bgamari

Reviewed By: bgamari

Subscribers: dfeuer, simonpj, thomie, carter

GHC Trac Issues: #15081

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

GHC previously had a handful of special cases for
pretty-printing equalities in a more user-friendly manner, but they
were far from comprehensive (see #15039 for an example of where this
fell apart).

This patch makes the pretty-printing of equalities much more
systematic. I've adopted the approach laid out in
https://ghc.haskell.org/trac/ghc/ticket/15039#comment:4, and updated
`Note [Equality predicates in IfaceType]` accordingly. We are now
more careful to respect the properties of the
`-fprint-explicit-kinds` and `-fprint-equality-relations` flags,
which led to some improvements in error message outputs.

Along the way, I also tweaked the error-reporting machinery not to
print out the type of a typed hole when the type is an unlifted
equality, since it's kind (`TYPE ('TupleRep '[])`) was more
confusing than anything.

Test Plan: make test TEST="T15039a T15039b T15039c T15039d"

Reviewers: simonpj, goldfire, bgamari

Reviewed By: simonpj

Subscribers: rwbarton, thomie, carter

GHC Trac Issues: #15039

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

Summary:
- Previously we would hvae a single big table of pointers per module,
  with a set of bitmaps to reference entries within it. The new
  representation is identical to a static constructor, which is much
  simpler for the GC to traverse, and we get to remove the complicated
  bitmap-traversal code from the GC.

- Rewrite all the code to generate SRTs in CmmBuildInfoTables, and
  document it much better (see Note [SRTs]). This has been something
  I've wanted to do since we moved to the new code generator, I
  finally had the opportunity to finish it while on a transatlantic
  flight recently :)

There are a series of 4 diffs:

1. D4632 (this one), which does the bulk of the changes

2. D4633 which adds support for smaller `CmmLabelDiffOff` constants

3. D4634 which takes advantage of D4632 and D4633 to save a word in
   info tables that have an SRT on x86_64. This is where most of the
   binary size improvement comes from.

4. D4637 which makes a further optimisation to merge some SRTs with
   static FUN closures.  This adds some complexity and the benefits
   are fairly modest, so it's not clear yet whether we should do this.

Results (after (3), on x86_64)

- GHC itself (staticaly linked) is 5.2% smaller

- -1.7% binary sizes in nofib, -2.9% module sizes. Full nofib results: P176

- I measured the overhead of traversing all the static objects in a
  major GC in GHC itself by doing `replicateM_ 1000 performGC` as the
  first thing in `Main.main`.  The new version was 5-10% faster, but
  the results did vary quite a bit.

- I'm not sure if there's a compile-time difference, the results are
  too unreliable.

Test Plan: validate

Reviewers: bgamari, michalt, niteria, simonpj, erikd, osa1

Subscribers: thomie, carter

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