Ben Gamari authored 1 year ago and Marge Bot committed 1 year ago

Updates all boot library submodules.

(cherry picked from commit 433d99a3)

Ben Gamari authored 1 year ago and Marge Bot committed 1 year ago

Bumps exceptions submodule.

(cherry picked from commit bf57fc9a)

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

Updates `text` and `exceptions` submodules for bounds bumps.

Addresses #22767.

Requires various submodule bumps.

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

Updates submodule

* Always rely on vendored filepath
* filepath must be built as stage0 dependency because it uses
  template-haskell.

Towards #22098

Douglas Wilson authored 2 years ago and Marge Bot committed 2 years ago

Vendoring with ../ in hs-source-dirs prevents upload to hackage.

(cherry picked from commit 1446be75)

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

Adding filepath as a dependency of template-haskell means that it can't
be reinstalled if any build-plan depends on template-haskell.

This is a temporary solution for the 9.4 release.

A longer term solution is to split-up the template-haskell package into
the wired-in part and a non-wired-in part which can be reinstalled. This
was deemed quite risky on the 9.4 release timescale.

Fixes #21738

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

Bumps text and exceptions submodules due to bounds.

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)

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>

This requires bumping the `exceptions` and `text` submodules to bring in
commits that bump their respective upper version bounds on `template-haskell`.

Fixes #19083.

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

Also bumps upper bounds on base in boot libraries (incl. submodules).

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

There are three problems with the current API:

1. It is hard to properly write instances for ``Quote m => m (TExp a)`` as the type is the composition
   of two type constructors. Doing so in your program involves making your own newtype and
   doing a lot of wrapping/unwrapping.

   For example, if I want to create a language which I can either run immediately or
   generate code from I could write the following with the new API. ::

      class Lang r where
        _int :: Int -> r Int
        _if  :: r Bool -> r a -> r a -> r a

      instance Lang Identity where
        _int = Identity
        _if (Identity b) (Identity t) (Identity f) = Identity (if b then t else f)

      instance Quote m => Lang (Code m) where
        _int = liftTyped
        _if cb ct cf = [|| if $$cb then $$ct else $$cf ||]

2. When doing code generation it is common to want to store code fragments in
   a map. When doing typed code generation, these code fragments contain a
   type index so it is desirable to store them in one of the parameterised
   map data types such as ``DMap`` from ``dependent-map`` or ``MapF`` from
   ``parameterized-utils``.

   ::

      compiler :: Env -> AST a -> Code Q a

      data AST a where ...
      data Ident a = ...

      type Env = MapF Ident (Code Q)

      newtype Code m a = Code (m (TExp a))

   In this example, the ``MapF`` maps an ``Ident String`` directly to a ``Code Q String``.
   Using one of these map types currently requires creating your own newtype and constantly
   wrapping every quotation and unwrapping it when using a splice. Achievable, but
   it creates even more syntactic noise than normal metaprogramming.

3. ``m (TExp a)`` is ugly to read and write, understanding ``Code m a`` is
   easier. This is a weak reason but one everyone
   can surely agree with.

Updates text submodule.

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

This requires bumping the `exceptions` and `text` submodules to bring
in commits that bump their respective upper version bounds on
`template-haskell`.

Fixes #17645. Fixes #17696.

Note that the new `text` commit includes a fair number of additions
to the Haddocks in that library. As a result, Haddock has to do more
work during the `haddock.Cabal` test case, increasing the number of
allocations it requires. Therefore,

-------------------------
Metric Increase:
    haddock.Cabal
-------------------------

Metric Increase:
    T4801

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

Commit cef80c0b debuted a breaking
change to `template-haskell`, so in order to guard against it
properly with CPP, we need to bump the `template-haskell` version
number accordingly.

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

Besides the obvious benefits of being able to manipulate `TExp`'s of
unboxed types, this also simplified `-XDeriveLift` all while making
it more capable.

  * `ghc-prim` is explicitly depended upon by `template-haskell`

  * The following TH things are parametrized over `RuntimeRep`:

      - `TExp(..)`
      - `unTypeQ`
      - `unsafeTExpCoerce`
      - `Lift(..)`

  * The following instances have been added to `Lift`:

      - `Int#`, `Word#`, `Float#`, `Double#`, `Char#`, `Addr#`
      - unboxed tuples of lifted types up to arity 7
      - unboxed sums of lifted types up to arity 7

    Ideally we would have levity-polymorphic _instances_ of unboxed
    tuples and sums.

  * The code generated by `-XDeriveLift` uses expression quotes
    instead of generating large amounts of TH code and having
    special hard-coded cases for some unboxed types.

Chaitanya Koparkar authored 6 years ago and Marge Bot committed 6 years ago

This patch only attempts to fix links that don't automatically re-direct to the correct URL.

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

Along the way, I discovered that `template-haskell.cabal` was
hard-coding the GHC version (in the form of its `ghc-boot-th` version
bounds), so I decided to make life a little simpler in the future by
generating `template-haskell.cabal` with autoconf.

Summary:
Commit 512eeb9b
(`More explicit foralls (GHC Proposal 0007)`) introduced breaking
changes to the Template Haskell AST. As a consequence of this, there
are libraries in the wild that now fail to build on GHC HEAD (for
instance, `th-abstraction`).

This properly bumps the `template-haskell` library's version number
to `2.15.0.0` so that these libraries can guard against these changes
using `MIN_VERSION_template_haskell`.

Test Plan: ./validate

Reviewers: bgamari

Reviewed By: bgamari

Subscribers: rwbarton, carter

GHC Trac Issues: #15818

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

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

This change was previously part of
[D4904](https://phabricator.haskell.org/D4904), but is being split off
to aid in getting this reviewed and merged.

* The compiler code is built with `NoImplicitPrelude`, but GHCi's
  modules are incompatible with it. So, this adds the pragma to all GHCi
  modules that didn't have it, and adds imports of Prelude.

* In order to run GHC within itself, a `call of 'initGCStatistics`
  needed to be skipped. This uses CPP to skip it when
  `-DGHC_LOADED_INTO_GHCI` is set.

* There is an environment variable workaround suggested by Ben Gamari
  [1], where `_GHC_TOP_DIR` can be used to specify GHC's top dir if `-B`
  isn't provided.  This can be used to solve a problem where the GHC being
  run within GHCi attempts to look in `inplace/lib/lib/` instead of
  `inplace/lib/`.

[1]: https://phabricator.haskell.org/D4904#135438

Reviewers: goldfire, bgamari, erikd, alpmestan

Reviewed By: alpmestan

Subscribers: alpmestan, lelf, rwbarton, thomie, carter

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

Bumps haddock submodule.

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

Bumps haddock submodule.

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

Summary:
There has been at least one breaking change to
`template-haskell` (the removal of `qAddForeignFile`) which is
causing packages like `th-orphans` and `singletons` to fail to build
with GHC HEAD. Let's bump `template-haskell`'s major version number
so that these packages can properly guard against these changes.

While I was in town, I also started a `changelog` section for
the next major version of `template-haskell`, and copied over
finishing touches for `template-haskell-2.13.0.0`.

Test Plan: ./validate

Reviewers: bgamari

Reviewed By: bgamari

Subscribers: thomie, carter

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

The ghc-8.4 branch has now been cut. Updates the haddock submodule.

Summary:
Now that `MonadIO` is a superclass of `Quasi`, it's a good
time to bump the `template-haskell` version so that libraries can
accommodate the change using CPP.

Test Plan: ./validate

Reviewers: bgamari, austin

Subscribers: rwbarton, thomie

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

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

In the past we needed the construct below for wired-in packages,
but since GHC 8.0 (which we require at least for stage0 now) the CLI has
stabilised, so we can unconditionally use `-this-unit-id` since GHC 8.0.

    if impl( ghc >= 7.11 )
	ghc-options:  -this-unit-id template-haskell
    else
	if impl( ghc >= 7.9 )
	    ghc-options:  -this-package-key template-haskell
	else
	    ghc-options:  -package-name template-haskell

Summary:
Types and kinds are now the same in GHC... well, except in the code
that involves Template Haskell, where types and kinds are given separate
treatment. This aims to unify that treatment in the `DsMeta` module.

The gist of this patch is replacing all uses of `repLKind` with `repLTy`.
This is isn't quite as simple as one might imagine, since `repLTy` returns a
`Core (Q Type)` (a monadic expression), whereas `repLKind` returns a
`Core Kind` (a pure expression). This causes many awkward impedance mismatches.

One option would be to change every combinator in `Language.Haskell.TH.Lib` to
take `KindQ` as an argument instead of `Kind`. But this would be a breaking
change of colossal proportions.

Instead, this patch takes a somewhat different approach. This migrates the
existing `Language.Haskell.TH.Lib` module to
`Language.Haskell.TH.Lib.Internal`, and changes all `Kind`-related combinators
in `Language.Haskell.TH.Lib.Internal` to live in `Q`. The new
`Language.Haskell.TH.Lib` module then re-exports most of
`Language.Haskell.TH.Lib.Internal` with the exception of the `Kind`-related
combinators, for which it redefines them to be their current definitions (which
don't live in `Q`). This allows us to retain backwards compatibility with
previous `template-haskell` releases, but more importantly, it allows GHC to
make as many changes to the `Internal` code as it wants for its purposes
without fear of disrupting the public API.

This solves half of #11785 (the other half being `TcSplice`).

Test Plan: ./validate

Reviewers: goldfire, austin, bgamari

Reviewed By: goldfire

Subscribers: rwbarton, thomie

GHC Trac Issues: #11785

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

Bumps haddock submodule

Updates a number of submodules.

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

This creates a new package, `ghc-boot-th`, to contain the `Extension`
type, which now lives in `GHC.LanguageExtension.Type`. This ensures that
the transitive dependency set of the `template-haskell` package remains
minimal.

The `GHC.LanguageExtensions.Type` module is also re-exported by
`ghc-boot`, which provides an orphan `binary` instance as well.

Test Plan: Validate

Reviewers: goldfire, thomie, hvr, austin

Reviewed By: thomie

Subscribers: RyanGlScott, thomie, erikd, ezyang

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

As per #6032, `Rank2Types` and `PolymorphicComponents` have been
deprecated in favour of `RankNTypes`.

also update `other-extensions` in template-haskell.cabal flag to
reflect reality.