Matthew Pickering authored 2 years ago and Marge Bot committed 2 years ago

In #22217 it was observed that the order modules are compiled in affects
the contents of an interface file. This was because a module dependended
on another module indirectly, via a re-export but the interface file for
this module was never loaded because the symbol was never used in the
file.

If we decide that we depend on a module then we jolly well ought to
record this fact in the interface file! Otherwise it could lead to very
subtle recompilation bugs if the dependency is not tracked and the
module is updated.

Therefore the best thing to do is just to make sure the file is loaded
by calling the `loadSysInterface` function.  This first checks the
caches (like we did before) but then actually goes to find the interface
on disk if it wasn't loaded.

Fixes #22217

Justification in #22231. Short form: In a demand like `1C1(C1(L))`
it was too easy to confuse which `1` belongs to which `C`. Now
that should be more obvious.

Fixes #22231

This patch comprises of four different but closely related ideas. The
net result is fixing a large number of open issues with the driver
whilst making it simpler to understand.

1. Use the hash of the source file to determine whether the source file
has changed or not. This makes the recompilation checking more robust to
modern build systems which are liable to copy files around changing
their modification times.

2. Remove the concept of a "stable module", a stable module was one
where the object file was older than the source file, and all transitive
dependencies were also stable. Now we don't rely on the modification
time of the source file, the notion of stability is moot.

3. Fix TH/plugin recompilation after the removal of stable modules. The
TH recompilation check used to rely on stable modules. Now there is a
uniform and simple way, we directly track the linkables which were
loaded into the interpreter whilst compiling a module. This is an
over-approximation but more robust wrt package dependencies changing.

4. Fix recompilation checking for dynamic object files. Now we actually
check if the dynamic object file exists when compiling with -dynamic-too

Fixes #19774 #19771 #19758 #17434 #11556 #9121 #8211 #16495 #7277 #16093

Matthew Pickering authored 3 years ago and Marge Bot committed 3 years ago

This commit modifies interface files so that *only* direct information
about modules and packages is stored in the interface file.

* Only direct module and direct package dependencies are stored in the
interface files.
* Trusted packages are now stored separately as they need to be checked
  transitively.
* hs-boot files below the compiled module in the home module are stored
  so that eps_is_boot can be calculated in one-shot mode without loading
  all interface files in the home package.
* The transitive closure of signatures is stored separately

This is important for two reasons

* Less recompilation is needed, as motivated by #16885, a lot of
redundant compilation was triggered when adding new imports deep in the
module tree as all the parent interface files had to be redundantly
updated.
* Checking an interface file is cheaper because you don't have to
perform a transitive traversal to check the dependencies are up-to-date.

In the code, places where we would have used the transitive closure, we
instead compute the necessary transitive closure. The closure is not
computed very often, was already happening in checkDependencies, and
was already happening in getLinkDeps.

Fixes #16885

-------------------------
Metric Decrease:
    MultiLayerModules
    T13701
    T13719
-------------------------

Fumiaki Kinoshita authored 4 years ago and Marge Bot committed 4 years ago

-------------------------
Metric Decrease:
   T12425
Metric Increase:
   T17516
-------------------------

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

Fixes #18279. Bumps the `text` submodule.

* support detection of slow ghc-bignum backend (to replace the detection
  of integer-simple use). There are still some test cases that the
  native backend doesn't handle efficiently enough.

* remove tests for GMP only functions that have been removed from
  ghc-bignum

* fix test results showing dependent packages (e.g. integer-gmp) or
  showing suggested instances

* fix test using Integer/Natural API or showing internal names

This patch simplifies GHC to use simple subsumption.
  Ticket #17775

Implements GHC proposal #287
   https://github.com/ghc-proposals/ghc-proposals/blob/master/
   proposals/0287-simplify-subsumption.rst

All the motivation is described there; I will not repeat it here.
The implementation payload:
 * tcSubType and friends become noticably simpler, because it no
   longer uses eta-expansion when checking subsumption.
 * No deeplyInstantiate or deeplySkolemise

That in turn means that some tests fail, by design; they can all
be fixed by eta expansion.  There is a list of such changes below.

Implementing the patch led me into a variety of sticky corners, so
the patch includes several othe changes, some quite significant:

* I made String wired-in, so that
    "foo" :: String   rather than
    "foo" :: [Char]
  This improves error messages, and fixes #15679

* The pattern match checker relies on knowing about in-scope equality
  constraints, andd adds them to the desugarer's environment using
  addTyCsDs.  But the co_fn in a FunBind was missed, and for some reason
  simple-subsumption ends up with dictionaries there. So I added a
  call to addTyCsDs.  This is really part of #18049.

* I moved the ic_telescope field out of Implication and into
  ForAllSkol instead.  This is a nice win; just expresses the code
  much better.

* There was a bug in GHC.Tc.TyCl.Instance.tcDataFamInstHeader.
  We called checkDataKindSig inside tc_kind_sig, /before/
  solveEqualities and zonking.  Obviously wrong, easily fixed.

* solveLocalEqualitiesX: there was a whole mess in here, around
  failing fast enough.  I discovered a bad latent bug where we
  could successfully kind-check a type signature, and use it,
  but have unsolved constraints that could fill in coercion
  holes in that signature --  aargh.

  It's all explained in Note [Failure in local type signatures]
  in GHC.Tc.Solver. Much better now.

* I fixed a serious bug in anonymous type holes. IN
    f :: Int -> (forall a. a -> _) -> Int
  that "_" should be a unification variable at the /outer/
  level; it cannot be instantiated to 'a'.  This was plain
  wrong.  New fields mode_lvl and mode_holes in TcTyMode,
  and auxiliary data type GHC.Tc.Gen.HsType.HoleMode.

  This fixes #16292, but makes no progress towards the more
  ambitious #16082

* I got sucked into an enormous refactoring of the reporting of
  equality errors in GHC.Tc.Errors, especially in
      mkEqErr1
      mkTyVarEqErr
      misMatchMsg
      misMatchMsgOrCND
  In particular, the very tricky mkExpectedActualMsg function
  is gone.

  It took me a full day.  But the result is far easier to understand.
  (Still not easy!)  This led to various minor improvements in error
  output, and an enormous number of test-case error wibbles.

  One particular point: for occurs-check errors I now just say
     Can't match 'a' against '[a]'
  rather than using the intimidating language of "occurs check".

* Pretty-printing AbsBinds

Tests review

* Eta expansions
   T11305: one eta expansion
   T12082: one eta expansion (undefined)
   T13585a: one eta expansion
   T3102:  one eta expansion
   T3692:  two eta expansions (tricky)
   T2239:  two eta expansions
   T16473: one eta
   determ004: two eta expansions (undefined)
   annfail06: two eta (undefined)
   T17923: four eta expansions (a strange program indeed!)
   tcrun035: one eta expansion

* Ambiguity check at higher rank.  Now that we have simple
  subsumption, a type like
     f :: (forall a. Eq a => Int) -> Int
  is no longer ambiguous, because we could write
     g :: (forall a. Eq a => Int) -> Int
     g = f
  and it'd typecheck just fine.  But f's type is a bit
  suspicious, and we might want to consider making the
  ambiguity check do a check on each sub-term.  Meanwhile,
  these tests are accepted, whereas they were previously
  rejected as ambiguous:
     T7220a
     T15438
     T10503
     T9222

* Some more interesting error message wibbles
   T13381: Fine: one error (Int ~ Exp Int)
           rather than two (Int ~ Exp Int, Exp Int ~ Int)
   T9834:  Small change in error (improvement)
   T10619: Improved
   T2414:  Small change, due to order of unification, fine
   T2534:  A very simple case in which a change of unification order
           means we get tow unsolved constraints instead of one
   tc211: bizarre impredicative tests; just accept this for now

Updates Cabal and haddock submodules.

Metric Increase:
  T12150
  T12234
  T5837
  haddock.base
Metric Decrease:
  haddock.compiler
  haddock.Cabal
  haddock.base

Merge note: This appears to break the
`UnliftedNewtypesDifficultUnification` test. It has been marked as
broken in the interest of merging.

(cherry picked from commit 66b7b195)

Sylvain Henry authored 4 years ago and Marge Bot committed 4 years ago

Update Haddock submodule

Metric Increase:
   haddock.compiler

* GHC.Core.Op                  => GHC.Core.Opt
* GHC.Core.Opt.Simplify.Driver => GHC.Core.Opt.Driver
* GHC.Core.Opt.Tidy            => GHC.Core.Tidy
* GHC.Core.Opt.WorkWrap.Lib    => GHC.Core.Opt.WorkWrap.Utils

As discussed in:
 * https://mail.haskell.org/pipermail/ghc-devs/2020-April/018758.html
 * #13009 (comment 264650)

Sylvain Henry authored 5 years ago and Marge Bot committed 5 years ago

Update Haddock submodule

Metric Increase:
   haddock.compiler

We now always show "forall {a}. T" for inferred variables,
previously this was controlled by -fprint-explicit-foralls.

This implements part 1 of https://github.com/ghc-proposals/ghc-proposals/pull/179.

Part of GHC ticket #16320.

Furthermore, when printing a levity restriction error, we now display
the HsWrap of the expression. This lets users see the full elaboration with
-fprint-typechecker-elaboration (see also #17670)

Vladislav Zavialov authored 5 years ago and Marge Bot committed 5 years ago

GHC Proposal #229 changes the lexical rules of Haskell, which may
require slight whitespace adjustments in certain cases.

This patch changes formatting in a few places in GHC and its testsuite
in a way that enables it to compile under the proposed rules.

Herbert Valerio Riedel authored 6 years ago and Ben Gamari committed 6 years ago

As per https://prime.haskell.org/wiki/Libraries/Proposals/MonadFail



Coauthored-by: Ben Gamari <ben@well-typed.com>

Alec Theriault authored 6 years ago and Marge Bot committed 6 years ago

Prevents some tests from failing just due to mismatched version numbers.

These version numbers shouldn't cause tests to fail, especially since
we *expect* them to be regularly incremented. The motivation for this
particular set of changes came from the changes that came along with
the `base` version bump in 8f19ecc9.

This eliminates most uses of run_command in the testsuite in favor of the more
structured makefile_test.

This reverts commit 76c8fd67.

This fixes a variety of testsuite failures with integer-simple of the form

```
--- typecheck/should_fail/tcfail072.run/tcfail072.stderr.normalised
+++ typecheck/should_fail/tcfail072.run/tcfail072.comp.stderr.normalised
@@ -12,7 +12,7 @@
           -- Defined in ‘integer-<IMPL>-<VERSION>:GHC.Integer.Type’
         instance Ord () -- Defined in ‘GHC.Classes’
         ...plus 21 others
-        ...plus three instances involving out-of-scope types
+        ...plus two instances involving out-of-scope types
         (use -fprint-potential-instances to see them all)
      In the expression: g A
       In an equation for ‘g’: g (B _ _) = g A
```

In service of fixing #16043.

This patch makes a number of improvements to the output
generated by -ddump-types

* Prints data constructor separately
* Omits empty chunks of output

I was driven initially by the unhelpful existing output for
data constructors, but ended up doing some refactoring.

Lots of error message wibbles, but nothing significant.
Certainly no change in user behaviour.

(NB: It is just possible that I have failed to cleanly
     separate this patch from the next one, about
     isPredTy and friends.)

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

Enabling -Werror=compat in the testsuite allows us to easily see the
impact that a new warning has on code. It also means that in the period
between adding the warning and making the actual breaking change, all
new test cases that are being added to the testsuite will be
forwards-compatible. This is good because it will make the actual
breaking change contain less irrelevant testsuite updates.

Things that -Wcompat warns about are things that are going to break in
the future, so we can be proactive and keep our testsuite
forwards-compatible.

This patch consists of two main changes:

* Add `TEST_HC_OPTS += -Werror=compat` to the testsuite configuration.
* Fix all broken test cases.

Test Plan: Validate

Reviewers: hvr, goldfire, bgamari, simonpj, RyanGlScott

Reviewed By: goldfire, RyanGlScott

Subscribers: rwbarton, carter

GHC Trac Issues: #15278

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

Herbert Valerio Riedel authored 6 years ago and Ben Gamari committed 6 years ago

Summary:
This contains two commits:

----

Make GHC's code-base compatible w/ `MonadFail`

There were a couple of use-sites which implicitly used pattern-matches
in `do`-notation even though the underlying `Monad` didn't explicitly
support `fail`

This refactoring turns those use-sites into explicit case
discrimations and adds an `MonadFail` instance for `UniqSM`
(`UniqSM` was the worst offender so this has been postponed for a
follow-up refactoring)

---

Turn on MonadFail desugaring by default

This finally implements the phase scheduled for GHC 8.6 according to

https://prime.haskell.org/wiki/Libraries/Proposals/MonadFail#Transitionalstrategy

This also preserves some tests that assumed MonadFail desugaring to be
active; all ghc boot libs were already made compatible with this
`MonadFail` long ago, so no changes were needed there.

Test Plan: Locally performed ./validate --fast

Reviewers: bgamari, simonmar, jrtc27, RyanGlScott

Reviewed By: bgamari

Subscribers: bgamari, RyanGlScott, rwbarton, thomie, carter

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

Summary:
Implement the "Embrace Type :: Type" GHC proposal,
.../ghc-proposals/blob/master/proposals/0020-no-type-in-type.rst

GHC 8.0 included a major change to GHC's type system: the Type :: Type
axiom. Though casual users were protected from this by hiding its
features behind the -XTypeInType extension, all programs written in GHC
8+ have the axiom behind the scenes. In order to preserve backward
compatibility, various legacy features were left unchanged. For example,
with -XDataKinds but not -XTypeInType, GADTs could not be used in types.
Now these restrictions are lifted and -XTypeInType becomes a redundant
flag that will be eventually deprecated.

* Incorporate the features currently in -XTypeInType into the
  -XPolyKinds and -XDataKinds extensions.
* Introduce a new extension -XStarIsType to control how to parse * in
  code and whether to print it in error messages.

Test Plan: Validate

Reviewers: goldfire, hvr, bgamari, alanz, simonpj

Reviewed By: goldfire, simonpj

Subscribers: rwbarton, thomie, mpickering, carter

GHC Trac Issues: #15195

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

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

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

This is mostly for congruence with 'subWordC#' and '{add,sub}IntC#'.
I found 'plusWord2#' while implementing this, which both lacks
documentation and has a slightly different specification than
'addWordC#', which means the generic implementation is unnecessarily
complex.

While I was at it, I also added lacking meta-information on PrimOps
and refactored 'subWordC#'s generic implementation to be branchless.

Reviewers: bgamari, simonmar, jrtc27, dfeuer

Reviewed By: bgamari, dfeuer

Subscribers: dfeuer, thomie, carter

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

Summary: Bumps several submodules.

Test Plan: ./validate

Reviewers: hvr, bgamari

Reviewed By: bgamari

Subscribers: thomie, carter

GHC Trac Issues: #15018

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

This takes care of bumping the `base` and `integer-gmp`
minor version numbers in anticipation of a GHC 8.4.2 release.

While I was in town, I also filled in a `@since TODO` Haddock
annotation for `powModSecInteger` in `integer-gmp` with
`1.0.2.0`, and updated the changelog accordingly.

Test Plan: ./validate

Reviewers: hvr, goldfire, bgamari

Reviewed By: bgamari

Subscribers: thomie, carter

GHC Trac Issues: #15025

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

Trac #14394 showed that it's possible to get redundant
constraints in the inferred provided constraints of a pattern
synonym.  This patch removes the redundancy with mkMinimalBySCs.

To do this I had to generalise the type of mkMinimalBySCs slightly.
And, to reduce confusing reversal, I made it stable: it now returns
its result in the same order as its input.  That led to a raft of
error message wibbles, mostly for the better.

This is prompted by the addition of `compareByteArrays#` in
e3ba26f8

NOTE: We may switch to synchronise `ghc-prim` with GHC's version at some point

Ben Gamari authored 7 years ago and Ben Gamari committed 7 years ago

Bumps numerous submodules.

Reviewers: austin, hvr

Subscribers: rwbarton, thomie

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

(cherry picked from commit 8c5405f6)

(cherry picked from commit 09396ec3)

niteria authored 7 years ago and Ben Gamari committed 7 years ago

The problem was that the generated label included
a freshly assigned Unique value.

Test Plan:
Added a new test and looked at the generated stub:

```
 #include "HsFFI.h"
 #ifdef __cplusplus
 extern "C" {
 #endif
 extern HsInt zdmainzdAzdAzuzzlzzgzzg(StgStablePtr the_stableptr);
 extern HsInt zdmainzdAzdAzumkStringWriter(StgStablePtr the_stableptr);
 #ifdef __cplusplus
 }
 #endif
```

./validate

Reviewers: simonmar, austin, bgamari

Reviewed By: simonmar

Subscribers: rwbarton, thomie

GHC Trac Issues: #13807

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

Matthew Pickering authored 7 years ago and Ben Gamari committed 7 years ago

This refactoring makes it more obvious when we are constructing
a Node for the digraph rather than a less useful 3-tuple.

Reviewers: austin, goldfire, bgamari, simonmar, dfeuer

Reviewed By: dfeuer

Subscribers: rwbarton, thomie

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

TcSimplify.decideQuantification was doing the Wrong Thing when
"growing" the type variables to quantify over. We were trying to do
this on a tyvar set where we'd split off the dependent type varaibles;
and we just got it wrong.  A kind variable wasn't being generalised
properly, with confusing knock on consequences.

All this led to Trac #13371 and Trac #13393.

This commit tidies it all up:

* The type TcDepVars is renamed as CandidateQTvs;
  and splitDepVarsOfType to candidateQTyVarsOfType

* The code in TcSimplify.decideQuantification is simpler.
  It no longer does the tricky "grow" stuff over TcDepVars.
  Instead it use ordinary VarSets (thereby eliminating the
  nasty growThetaTyVarsDSet) and uses that to filter the
  result of candidateQTyVarsOfType.

* I documented that candidateQTyVarsOfType returns the type
  variables in a good order in which to quantify, and rewrote
  it to use an accumulator pattern, so that we would predicatably
  get left-to-right ordering.

In doing all this I also made UniqDFM behave a little more nicely:

* When inserting an element that is there already, keep the old tag,
  while still overwriting with the new value.

* This means that when doing udfmToList we get back elements in the
  order they were originally inserted, rather than in reverse order.

It's not a big deal, but in a subsequent commit I use it to improve
the order of type variables in inferred types.

All this led to a lot of error message wibbles:
 - changing the order of quantified variables
 - changing the order in which instances are listed in GHCi
 - changing the tidying of variables in typechecker erors

There's a submodule update for 'array' because one of its tests
has an error-message change.

I may not have associated all of them with the correct commit.

Ben Gamari authored 8 years ago and Ben Gamari committed 8 years ago

Test Plan: Validate

Reviewers: niteria, austin, dfeuer

Reviewed By: dfeuer

Subscribers: simonpj, thomie

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