Bartłomiej Cieślar authored 1 year ago and Ben Gamari committed 1 year ago

This is an implementation of the deprecated exports proposal #134.
The proposal introduces an ability to introduce warnings to exports.
This allows for deprecating a name only when it is exported from a specific
module, rather than always depreacting its usage. In this example:

    module A ({-# DEPRECATED "do not use" #-} x) where
    x = undefined
    ---
    module B where
    import A(x)

`x` will emit a warning when it is explicitly imported.

Like the declaration warnings, export warnings are first accumulated within
the `Warnings` struct, then passed into the ModIface, from which they are
then looked up and warned about in the importing module in the `lookup_ie`
helpers of the `filterImports` function (for the explicitly imported names)
and in the `addUsedGRE(s)` functions where they warn about regular usages
of the imported name.

In terms of the AST information, the custom warning is stored in the
extension field of the variants of the `IE` type (see Trees that Grow for
more information).

The commit includes a bump to the haddock submodule added in MR #28

Signed-off-by: Bartłomiej Cieślar <bcieslar2001@gmail.com>

Sylvain Henry authored 1 year ago and Marge Bot committed 1 year ago

Replace #22356 with #22349 for these tests because #22356 has been fixed
but now these tests fail because of #22349.

Bartłomiej Cieślar authored 1 year ago and Marge Bot committed 1 year ago

In some cases, backpack signature merging could crash in addUsedGRE
when -ddump-rn-trace was enabled, as pretty-printing the GREInfo would cause
unavailable interfaces to be loaded.
This commit fixes that issue by not pretty-printing the GREInfo in addUsedGRE
when -ddump-rn-trace is enabled.

Fixes #23424

Signed-off-by: Bartłomiej Cieślar <bcieslar2001@gmail.com>

This change makes command line argument parsing use diagnostic
framework for producing warnings.

sheaf authored 1 year ago and Marge Bot committed 1 year ago

This commit migrates the errors in GHC.Tc.Module to use the new
diagnostic infrastructure.

It required a significant overhaul of the compatibility checks between
an hs-boot or signature module and its implementation; we now use
a Writer monad to accumulate errors; see the BootMismatch datatype
in GHC.Tc.Errors.Types, with its panoply of subtypes.
For the sake of readability, several local functions inside the
'checkBootTyCon' function were split off into top-level functions.

We split off GHC.Types.HscSource into a "boot or sig" vs "normal hs file"
datatype, as this mirrors the logic in several other places where we
want to treat hs-boot and hsig files in a similar fashion.

This commit also refactors the Backpack checks for type synonyms
implementing abstract data, to correctly reject implementations that
contain qualified or quantified types (this fixes #23342 and #23344).

Rodrigo Mesquita authored 2 years ago and Marge Bot committed 1 year ago

This commit adds support for computing an inputs hash for packages
compiled by hadrian. The result is that ABI incompatible packages should
be given different hashes and therefore be distinct in a cabal store.

Hashing is enabled by the `--flag`, and is off by default as the hash
contains a hash of the source files. We enable it when we produce
release builds so that the artifacts we distribute have the right unit
ids.

Torsten Schmits authored 1 year ago and Marge Bot committed 1 year ago

Tracking ticket: #20117

MR: !10251

This converts uses of `mkTcRnUnknownMessage` to newly added constructors
of `TcRnMessage`.

This patch moves the field-based logic for disambiguating record updates
to the renamer. The type-directed logic, scheduled for removal, remains
in the typechecker.

To do this properly (and fix the myriad of bugs surrounding the treatment
of duplicate record fields), we took the following main steps:

  1. Create GREInfo, a renamer-level equivalent to TyThing which stores
     information pertinent to the renamer.
     This allows us to uniformly treat imported and local Names in the
     renamer, as described in Note [GREInfo].

  2. Remove GreName. Instead of a GlobalRdrElt storing GreNames, which
     distinguished between normal names and field names, we now store
     simple Names in GlobalRdrElt, along with the new GREInfo information
     which allows us to recover the FieldLabel for record fields.

  3. Add namespacing for record fields, within the OccNames themselves.
     This allows us to remove the mangling of duplicate field selectors.

     This change ensures we don't print mangled names to the user in
     error messages, and allows us to handle duplicate record fields
     in Template Haskell.

  4. Move record disambiguation to the renamer, and operate on the
     level of data constructors instead, to handle #21443.

     The error message text for ambiguous record updates has also been
     changed to reflect that type-directed disambiguation is on the way
     out.

(3) means that OccEnv is now a bit more complex: we first key on the
textual name, which gives an inner map keyed on NameSpace:

  OccEnv a ~ FastStringEnv (UniqFM NameSpace a)

Note that this change, along with (2), both increase the memory residency
of GlobalRdrEnv = OccEnv [GlobalRdrElt], which causes a few tests to
regress somewhat in compile-time allocation.

Even though (3) simplified a lot of code (in particular the treatment of
field selectors within Template Haskell and in error messages), it came
with one important wrinkle: in the situation of

  -- M.hs-boot
  module M where { data A; foo :: A -> Int }
  -- M.hs
  module M where { data A = MkA { foo :: Int } }

we have that M.hs-boot exports a variable foo, which is supposed to match
with the record field foo that M exports. To solve this issue, we add a
new impedance-matching binding to M

  foo{var} = foo{fld}

This mimics the logic that existed already for impedance-binding DFunIds,
but getting it right was a bit tricky.
See Note [Record field impedance matching] in GHC.Tc.Module.

We also needed to be careful to avoid introducing space leaks in GHCi.
So we dehydrate the GlobalRdrEnv before storing it anywhere, e.g. in
ModIface. This means stubbing out all the GREInfo fields, with the
function forceGlobalRdrEnv.
When we read it back in, we rehydrate with rehydrateGlobalRdrEnv.
This robustly avoids any space leaks caused by retaining old type
environments.

Fixes #13352 #14848 #17381 #17551 #19664 #21443 #21444 #21720 #21898 #21946 #21959 #22125 #22160 #23010 #23062 #23063

Updates haddock submodule

-------------------------
Metric Increase:
    MultiComponentModules
    MultiLayerModules
    MultiLayerModulesDefsGhci
    MultiLayerModulesNoCode
    T13701
    T14697
    hard_hole_fits
-------------------------

Torsten Schmits authored 2 years ago and Marge Bot committed 2 years ago

Tracking ticket: #20119

MR: !10127

This converts uses of `mkTcRnUnknownMessage` to newly added constructors
of `TcRnMessage`.
One occurrence, when handing a nested error from the interface loading
machinery, was omitted. It will be handled by a subsequent changeset
that addresses interface errors.

Requires various submodule bumps.

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

Add JS backend adapted from the GHCJS project by Luite Stegeman.

Some features haven't been ported or implemented yet. Tests for these
features have been disabled with an associated gitlab ticket.

Bump array submodule

Work funded by IOG.

Co-authored-by: Jeffrey Young <jeffrey.young@iohk.io>
Co-authored-by: Luite Stegeman <stegeman@gmail.com>
Co-authored-by: Josh Meredith <joshmeredith2008@gmail.com>

Giles Anderson authored 2 years ago and Marge Bot committed 2 years ago

The following `TcRnDiagnostic` messages have been introduced:

TcRnWarnUnsatisfiedMinimalDefinition
TcRnMisplacedInstSig
TcRnBadBootFamInstDeclErr
TcRnIllegalFamilyInstance
TcRnAssocInClassErr
TcRnBadFamInstDecl
TcRnNotOpenFamily

Necessary for newer cross-compiling backends (JS, Wasm) that don't
support TH yet.

Torsten Schmits authored 2 years ago and Marge Bot committed 2 years ago

Part of proposal 475 (https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0475-tuple-syntax.rst)

Moves all tuples to GHC.Tuple.Prim
Updates ghc-prim version (and bumps bounds in dependents)

updates haddock submodule
updates deepseq submodule
updates text submodule

sheaf authored 2 years ago and Marge Bot committed 2 years ago

The testsuite output now contains diagnostic codes, so many tests need
to be updated at once.
We decided it was best to keep the diagnostic codes in the testsuite
output, so that contributors don't inadvertently make changes to the
diagnostic codes.

The following `TcRnDiagnostic` messages have been introduced:

TcRnIllegalHsigDefaultMethods
TcRnBadGenericMethod
TcRnWarningMinimalDefIncomplete
TcRnDefaultMethodForPragmaLacksBinding
TcRnIgnoreSpecialisePragmaOnDefMethod
TcRnBadMethodErr
TcRnNoExplicitAssocTypeOrDefaultDeclaration

Soham Chowdhury authored 2 years ago and Marge Bot committed 2 years ago

This patch improves the uniformity of error message formatting by
printing constraints in quotes, as we do for types.

Fix #21167

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

To 0.9.0 and 4.17.0 respectively.

Bumps array, deepseq, directory, filepath, haskeline, hpc, parsec, stm,
terminfo, text, unix, haddock, and hsc2hs submodules.

(cherry picked from commit ba47b951)

HaskellMouse authored 2 years ago and Marge Bot committed 2 years ago

This commit fixes #20312
It deprecates "TypeInType" extension
according to the following proposal:
https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0083-no-type-in-type.rst

It has been already implemented.

The migration strategy:
 1. Disable TypeInType
 2. Enable both DataKinds and PolyKinds extensions

Metric Decrease:
    T16875

Krzysztof Gogolewski authored 2 years ago and Matthew Pickering committed 2 years ago

Users are supposed to import GHC.Exts rather than GHC.Prim.
Part of #18749.

* Users can define their own (~) type operator
* Haddock can display documentation for the built-in (~)
* New transitional warnings implemented:
    -Wtype-equality-out-of-scope
    -Wtype-equality-requires-operators

Updates the haddock submodule.

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

As noted in #21071 we were missing adding this edge so there were
situations where the .hs file would get compiled before the .hs-boot
file which leads to issues with -j.

I fixed this properly by adding the edge in downsweep so the definition
of nodeDependencies can be simplified to avoid adding this dummy edge
in.

There are plenty of tests which seem to have these redundant boot files
anyway so no new test. #21094 tracks the more general issue of
identifying redundant hs-boot and SOURCE imports.

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

Here we introduce a new data structure, RoughMap, inspired by the
previous `RoughTc` matching mechanism for checking instance matches.
This allows [Fam]InstEnv to be implemented as a trie indexed by these
RoughTc signatures, reducing the complexity of instance lookup and
FamInstEnv merging (done during the family instance conflict test)
from O(n) to O(log n).

The critical performance improvement currently realised by this patch is
in instance matching. In particular the RoughMap mechanism allows us to
discount many potential instances which will never match for constraints
involving type variables (see Note [Matching a RoughMap]). In realistic
code bases matchInstEnv was accounting for 50% of typechecker time due
to redundant work checking instances when simplifying instance contexts
when deriving instances. With this patch the cost is significantly
reduced.

The larger constants in InstEnv creation do mean that a few small
tests regress in allocations slightly. However, the runtime of T19703 is
reduced by a factor of 4. Moreover, the compilation time of the Cabal
library is slightly improved.

A couple of test cases are included which demonstrate significant
improvements in compile time with this patch.

This unfortunately does not fix the testcase provided in #19703 but does
fix #20933

-------------------------
Metric Decrease:
    T12425
Metric Increase:
    T13719
    T9872a
    T9872d
    hard_hole_fits
-------------------------

Co-authored-by: Matthew Pickering <matthewtpickering@gmail.com>

Multiple home units allows you to load different packages which may depend on
each other into one GHC session. This will allow both GHCi and HLS to support
multi component projects more naturally.

Public Interface
~~~~~~~~~~~~~~~~

In order to specify multiple units, the -unit @⟨filename⟩ flag
is given multiple times with a response file containing the arguments for each unit.
The response file contains a newline separated list of arguments.

```
ghc -unit @unitLibCore -unit @unitLib
```

where the `unitLibCore` response file contains the normal arguments that cabal would pass to `--make` mode.

```
-this-unit-id lib-core-0.1.0.0
-i
-isrc
LibCore.Utils
LibCore.Types
```

The response file for lib, can specify a dependency on lib-core, so then modules in lib can use modules from lib-core.

```
-this-unit-id lib-0.1.0.0
-package-id lib-core-0.1.0.0
-i
-isrc
Lib.Parse
Lib.Render
```

Then when the compiler starts in --make mode it will compile both units lib and lib-core.

There is also very basic support for multiple home units in GHCi, at the
moment you can start a GHCi session with multiple units but only the
:reload is supported. Most commands in GHCi assume a single home unit,
and so it is additional work to work out how to modify the interface to
support multiple loaded home units.

Options used when working with Multiple Home Units

There are a few extra flags which have been introduced specifically for
working with multiple home units. The flags allow a home unit to pretend
it’s more like an installed package, for example, specifying the package
name, module visibility and reexported modules.

-working-dir ⟨dir⟩

    It is common to assume that a package is compiled in the directory
    where its cabal file resides. Thus, all paths used in the compiler
    are assumed to be relative to this directory. When there are
    multiple home units the compiler is often not operating in the
    standard directory and instead where the cabal.project file is
    located. In this case the -working-dir option can be passed which
    specifies the path from the current directory to the directory the
    unit assumes to be it’s root, normally the directory which contains
    the cabal file.

    When the flag is passed, any relative paths used by the compiler are
    offset by the working directory. Notably this includes -i and
    -I⟨dir⟩ flags.

-this-package-name ⟨name⟩

    This flag papers over the awkward interaction of the PackageImports
    and multiple home units. When using PackageImports you can specify
    the name of the package in an import to disambiguate between modules
    which appear in multiple packages with the same name.

    This flag allows a home unit to be given a package name so that you
    can also disambiguate between multiple home units which provide
    modules with the same name.

-hidden-module ⟨module name⟩

    This flag can be supplied multiple times in order to specify which
    modules in a home unit should not be visible outside of the unit it
    belongs to.

    The main use of this flag is to be able to recreate the difference
    between an exposed and hidden module for installed packages.

-reexported-module ⟨module name⟩

    This flag can be supplied multiple times in order to specify which
    modules are not defined in a unit but should be reexported. The
    effect is that other units will see this module as if it was defined
    in this unit.

    The use of this flag is to be able to replicate the reexported
    modules feature of packages with multiple home units.

Offsetting Paths in Template Haskell splices
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

When using Template Haskell to embed files into your program,
traditionally the paths have been interpreted relative to the directory
where the .cabal file resides. This causes problems for multiple home
units as we are compiling many different libraries at once which have
.cabal files in different directories.

For this purpose we have introduced a way to query the value of the
-working-dir flag to the Template Haskell API. By using this function we
can implement a makeRelativeToProject function which offsets a path
which is relative to the original project root by the value of
-working-dir.

```
import Language.Haskell.TH.Syntax ( makeRelativeToProject )

foo = $(makeRelativeToProject "./relative/path" >>= embedFile)
```

> If you write a relative path in a Template Haskell splice you should use the makeRelativeToProject function so that your library works correctly with multiple home units.

A similar function already exists in the file-embed library. The
function in template-haskell implements this function in a more robust
manner by honouring the -working-dir flag rather than searching the file
system.

Closure Property for Home Units
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

For tools or libraries using the API there is one very important closure
property which must be adhered to:

> Any dependency which is not a home unit must not (transitively) depend
  on a home unit.

For example, if you have three packages p, q and r, then if p depends on
q which depends on r then it is illegal to load both p and r as home
units but not q, because q is a dependency of the home unit p which
depends on another home unit r.

If you are using GHC by the command line then this property is checked,
but if you are using the API then you need to check this property
yourself. If you get it wrong you will probably get some very confusing
errors about overlapping instances.

Limitations of Multiple Home Units
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

There are a few limitations of the initial implementation which will be smoothed out on user demand.

    * Package thinning/renaming syntax is not supported
    * More complicated reexports/renaming are not yet supported.
    * It’s more common to run into existing linker bugs when loading a
      large number of packages in a session (for example #20674, #20689)
    * Backpack is not yet supported when using multiple home units.
    * Dependency chasing can be quite slow with a large number of
      modules and packages.
    * Loading wired-in packages as home units is currently not supported
      (this only really affects GHC developers attempting to load
      template-haskell).
    * Barely any normal GHCi features are supported, it would be good to
      support enough for ghcid to work correctly.

Despite these limitations, the implementation works already for nearly
all packages. It has been testing on large dependency closures,
including the whole of head.hackage which is a total of 4784 modules
from 452 packages.

Internal Changes
~~~~~~~~~~~~~~~~

* The biggest change is that the HomePackageTable is replaced with the
  HomeUnitGraph. The HomeUnitGraph is a map from UnitId to HomeUnitEnv,
  which contains information specific to each home unit.
* The HomeUnitEnv contains:
    - A unit state, each home unit can have different package db flags
    - A set of dynflags, each home unit can have different flags
    - A HomePackageTable
* LinkNode: A new node type is added to the ModuleGraph, this is used to
  place the linking step into the build plan so linking can proceed in
  parralel with other packages being built.
* New invariant: Dependencies of a ModuleGraphNode can be completely
  determined by looking at the value of the node. In order to achieve
  this, downsweep now performs a more complete job of downsweeping and
  then the dependenices are recorded forever in the node rather than
  being computed again from the ModSummary.
* Some transitive module calculations are rewritten to use the
  ModuleGraph which is more efficient.
* There is always an active home unit, which simplifies modifying a lot
  of the existing API code which is unit agnostic (for example, in the
  driver).

The road may be bumpy for a little while after this change but the
basics are well-tested.

One small metric increase, which we accept and also submodule update to
haddock which removes ExtendedModSummary.

Closes #10827

-------------------------
Metric Increase:
    MultiLayerModules
-------------------------

Co-authored-by: Fendor <power.walross@gmail.com>

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

This test checks to see whether a signature can depend on another home
module. Whether it should or not is up for debate, see #20509 for
more details.

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

There is a latent issue in T16219 where -dynamic-too is enabled
when compiling a signature file which causes us to enter the DT_Failed
state because library-a-impl doesn't generate dyn_o files. Somehow this
used to work in 8.10 (that also entered the DT_Failed state)

We don't need dynamic object files when compiling a signature file but
the code loads interfaces, and if dynamic-too is enabled then it will
also try to load the dyn_hi file and check the two are consistent.
There is another hack to do with this in `GHC.Iface.Recomp`.

The fix for this test is to remove CABAL_MINIMAL_CONFIGURATION, which
stops cabal building shared libraries by default.

I'm of the opinion that the DT_Failed state indicates an error somewhere
so we should hard fail rather than this confusing (broken) rerun logic.

Whether this captures the original intent of #16219 is debateable, but
it's not clear how it was supposed to work in the first place if the
libraries didn't build dynamic object files. Module C imports module A,
which is from a library where shared objects are not built so the test
would never have worked anyway (if anything from A was used in a TH
splice).

sheaf authored 3 years ago and Marge Bot committed 3 years ago

PHASE 1: we never rewrite Concrete# evidence.

This patch migrates all the representation polymorphism checks to
the typechecker, using a new constraint form

  Concrete# :: forall k. k -> TupleRep '[]

Whenever a type `ty` must be representation-polymorphic
(e.g. it is the type of an argument to a function), we emit a new
`Concrete# ty` Wanted constraint. If this constraint goes
unsolved, we report a representation-polymorphism error to the user.
The 'FRROrigin' datatype keeps track of the context of the
representation-polymorphism check, for more informative error messages.

This paves the way for further improvements, such as
allowing type families in RuntimeReps and improving the soundness
of typed Template Haskell. This is left as future work (PHASE 2).

fixes #17907 #20277 #20330 #20423 #20426

updates haddock submodule

-------------------------
Metric Decrease:
    T5642
-------------------------

sheaf authored 3 years ago and Marge Bot committed 3 years ago

  Backpack used to initialise the logger before obtaining the
  DynFlags. This meant that logging options (such as dump flags)
  were not set.
  Initialising the logger after the session flags have been set
  fixes the issue.

  fixes #20396

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

The BSD sed implementation doesn't allow `sed -i COMMAND FILE`; one must
rather use `sed -i -e COMMAND FILE`.

Converts uses of TcRnUnknownMessage in GHC.Iface.Rename.

Closes #19927

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

This was an oversight from !6718

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

This patch specifies and simplifies the module cycle compilation
in upsweep. How things work are described in the Note [Upsweep]

Note [Upsweep]
~~~~~~~~~~~~~~

Upsweep takes a 'ModuleGraph' as input, computes a build plan and then executes
the plan in order to compile the project.

The first step is computing the build plan from a 'ModuleGraph'.

The output of this step is a `[BuildPlan]`, which is a topologically sorted plan for
how to build all the modules.

```
data BuildPlan = SingleModule ModuleGraphNode  -- A simple, single module all alone but *might* have an hs-boot file which isn't part of a cycle
               | ResolvedCycle [ModuleGraphNode]   -- A resolved cycle, linearised by hs-boot files
               | UnresolvedCycle [ModuleGraphNode] -- An actual cycle, which wasn't resolved by hs-boot files
```

The plan is computed in two steps:

Step 1: Topologically sort the module graph without hs-boot files. This returns a [SCC ModuleGraphNode] which contains
        cycles.
Step 2: For each cycle, topologically sort the modules in the cycle *with* the relevant hs-boot files. This should
        result in an acyclic build plan if the hs-boot files are sufficient to resolve the cycle.

The `[BuildPlan]` is then interpreted by the `interpretBuildPlan` function.

* `SingleModule nodes` are compiled normally by either the upsweep_inst or upsweep_mod functions.
* `ResolvedCycles` need to compiled "together" so that the information which ends up in
  the interface files at the end is accurate (and doesn't contain temporary information from
  the hs-boot files.)
  - During the initial compilation, a `KnotVars` is created which stores an IORef TypeEnv for
    each module of the loop. These IORefs are gradually updated as the loop completes and provide
    the required laziness to typecheck the module loop.
  - At the end of typechecking, all the interface files are typechecked again in
    the retypecheck loop. This time, the knot-tying is done by the normal laziness
    based tying, so the environment is run without the KnotVars.
* UnresolvedCycles are indicative of a proper cycle, unresolved by hs-boot files
  and are reported as an error to the user.

The main trickiness of `interpretBuildPlan` is deciding which version of a dependency
is visible from each module. For modules which are not in a cycle, there is just
one version of a module, so that is always used. For modules in a cycle, there are two versions of
'HomeModInfo'.

1. Internal to loop: The version created whilst compiling the loop by upsweep_mod.
2. External to loop: The knot-tied version created by typecheckLoop.

Whilst compiling a module inside the loop, we need to use the (1). For a module which
is outside of the loop which depends on something from in the loop, the (2) version
is used.

As the plan is interpreted, which version of a HomeModInfo is visible is updated
by updating a map held in a state monad. So after a loop has finished being compiled,
the visible module is the one created by typecheckLoop and the internal version is not
used again.

This plan also ensures the most important invariant to do with module loops:

> If you depend on anything within a module loop, before you can use the dependency,
  the whole loop has to finish compiling.

The end result of `interpretBuildPlan` is a `[MakeAction]`, which are pairs
of `IO a` actions and a `MVar (Maybe a)`, somewhere to put the result of running
the action. This list is topologically sorted, so can be run in order to compute
the whole graph.

As well as this `interpretBuildPlan` also outputs an `IO [Maybe (Maybe HomeModInfo)]` which
can be queried at the end to get the result of all modules at the end, with their proper
visibility. For example, if any module in a loop fails then all modules in that loop will
report as failed because the visible node at the end will be the result of retypechecking
those modules together.

Along the way we also fix a number of other bugs in the driver:

* Unify upsweep and parUpsweep.
* Fix #19937 (static points, ghci and -j)
* Adds lots of module loop tests due to Divam.

Also related to #20030

Co-authored-by: Divam Narula <dfordivam@gmail.com>

-------------------------
Metric Decrease:
    T10370
-------------------------

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

- Change the names of the fields in in `data FieldOcc`
- Renames `HsRecFld` to `HsRecSel`
- Replace `AmbiguousFieldOcc p` in `HsRecSel` with `FieldOcc p`
- Contains a haddock submodule update

The primary motivation of this change is to remove
`AmbiguousFieldOcc`. This is one of a suite of changes improving how
record syntax (most notably record update syntax) is represented in
the AST.