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

Plugins were directly fetched from HscEnv (hsc_static_plugins and
hsc_plugins). The tight coupling of plugins and of HscEnv is undesirable
and it's better to store them in a new Plugins datatype and to use it in
the plugins' API (e.g. withPlugins, mapPlugins...).

In the process, the interactive context (used by GHCi) got proper
support for different static plugins than those used for loaded modules.

Bump haddock submodule

Introduce LogFlags as a independent subset of DynFlags used for logging.
As a consequence in many places we don't have to pass both Logger and
DynFlags anymore.

The main reason for this refactoring is that I want to refactor the
systools interfaces: for now many systools functions use DynFlags both
to use the Logger and to fetch their parameters (e.g. ldInputs for the
linker). I'm interested in refactoring the way they fetch their
parameters (i.e. use dedicated XxxOpts data types instead of DynFlags)
for #19877. But if I did this refactoring before refactoring the Logger,
we would have duplicate parameters (e.g. ldInputs from DynFlags and
linkerInputs from LinkerOpts). Hence this patch first.

Some flags don't really belong to LogFlags because they are subsystem
specific (e.g. most DumpFlags). For example -ddump-asm should better be
passed in NCGConfig somehow. This patch doesn't fix this tight coupling:
the dump flags are part of the UI but they are passed all the way down
for example to infer the file name for the dumps.

Because LogFlags are a subset of the DynFlags, we must update the former
when the latter changes (not so often). As a consequence we now use
accessors to read/write DynFlags in HscEnv instead of using `hsc_dflags`
directly.

In the process I've also made some subsystems less dependent on DynFlags:

- CmmToAsm: by passing some missing flags via NCGConfig (see new fields
  in GHC.CmmToAsm.Config)
- Core.Opt.*:
    - by passing -dinline-check value into UnfoldingOpts
    - by fixing some Core passes interfaces (e.g. CallArity, FloatIn)
      that took DynFlags argument for no good reason.
    - as a side-effect GHC.Core.Opt.Pipeline.doCorePass is much less
      convoluted.

Hannes Siebenhandl authored 4 years ago and Marge Bot committed 4 years ago

In the future, we want `HscEnv` to support multiple home units
at the same time. This means, that there will be 'Target's that do
not belong to the current 'HomeUnit'.

This is an API change without changing behaviour.

Update haddock submodule to incorporate API changes.

John Ericson authored 4 years ago and Marge Bot committed 4 years ago

----------------
What:

There are two splits.

The first spit is:

 - `Language.Haskell.Syntax.Extension`
 - `GHC.Hs.Extension`

where the former now just contains helpers like `NoExtCon` and all the
families, and the latter is everything having to do with `GhcPass`.

The second split is:

 - `Language.Haskell.Syntax.<mod>`
 - `GHC.Hs.<mod>`

Where the former contains all the data definitions, and the few helpers
that don't use `GhcPass`, and the latter contains everything else. The
second modules also reexport the former.

----------------
Why:

See the issue for more details, but in short answer is we're trying to
grasp at the modularity TTG is supposed to offer, after a long time of
mainly just getting the safety benefits of more complete pattern
matching on the AST.

Now, we have an AST datatype which, without `GhcPass` is decently
stripped of GHC-specific concerns. Whereas before, not was it
GHC-specific, it was aware of all the GHC phases despite the
parameterization, with the instances and parametric data structure
side-by-side.

For what it's worth there are also some smaller, imminent benefits:

- The latter change also splits a strongly connected component in two,
  since none of the `Language.Haskell.Syntax.*` modules import the older
  ones.

- A few TTG violations (Using GhcPass directly in the AST) in `Expr` are
  now more explicitly accounted for with new type families to provide the
  necessary indirection.

-----------------
Future work:

- I don't see why all the type families should live in
  `Language.Haskell.Syntax.Extension`. That seems anti-modular for
  little benefit. All the ones used just once can be moved next to the
  AST type they serve as an extension point for.

- Decide what to do with the `Outputable` instances. Some of these are
  no orphans because they referred to `GhcPass`, and had to be moved. I
  think the types could be generalized so they don't refer to `GhcPass`
  and therefore can be moved back, but having gotten flak for increasing
  the size and complexity types when generalizing before, I did *not*
  want to do this.

- We should triage the remaining contents of `GHC.Hs.<mod>`. The
  renaming helpers are somewhat odd for needing `GhcPass`. We might
  consider if they are a) in fact only needed by one phase b) can be
  generalized to be non-GhcPass-specific (e.g. take a callback rather
  than GADT-match with `IsPass`) and then they can live in
  `Language.Haskell.Syntax.<mod>`.

For more details, see
https://gitlab.haskell.org/ghc/ghc/-/wikis/implementing-trees-that-grow

Bumps Haddock submodule

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

Loaded plugins have nothing to do in DynFlags so this patch moves them
into HscEnv (session state).

"DynFlags plugins" become "Driver plugins" to still be able to register
static plugins.

Bump haddock submodule

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

1) Don't modify DynFlags (too much) for -dynamic-too: now when we
   generate dynamic outputs for "-dynamic-too", we only set "dynamicNow"
   boolean field in DynFlags instead of modifying several other fields.
   These fields now have accessors that take dynamicNow into account.

2) Use DynamicTooState ADT to represent -dynamic-too state. It's much
   clearer than the undocumented "DynamicTooConditional" that was used
   before.

As a result, we can finally remove the hscs_iface_dflags field in
HscRecomp. There was a comment on this field saying:

   "FIXME (osa): I don't understand why this is necessary, but I spent
   almost two days trying to figure this out and I couldn't .. perhaps
   someone who understands this code better will remove this later."

I don't fully understand the details, but it was needed because of the
changes made to the DynFlags for -dynamic-too.

There is still something very dubious in GHC.Iface.Recomp: we have to
disable the "dynamicNow" flag at some point for some Backpack's "heinous
hack" to continue to work. It may be because interfaces for indefinite
units are always non-dynamic, or because we mix and match dynamic and
non-dynamic interfaces (#9176), or something else, who knows?

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

I was working on making DynFlags stateless (#17957), especially by
storing loaded plugins into HscEnv instead of DynFlags. It turned out to
be complicated because HscEnv is in GHC.Driver.Types but LoadedPlugin
isn't: it is in GHC.Driver.Plugins which depends on GHC.Driver.Types. I
didn't feel like introducing yet another hs-boot file to break the loop.

Additionally I remember that while we introduced the module hierarchy
(#13009) we talked about splitting GHC.Driver.Types because it contained
various unrelated types and functions, but we never executed. I didn't
feel like making GHC.Driver.Types bigger with more unrelated Plugins
related types, so finally I bit the bullet and split GHC.Driver.Types.

As a consequence this patch moves a lot of things. I've tried to put
them into appropriate modules but nothing is set in stone.

Several other things moved to avoid loops.

* Removed Binary instances from GHC.Utils.Binary for random compiler
  things
* Moved Typeable Binary instances into GHC.Utils.Binary.Typeable: they
  import a lot of things that users of GHC.Utils.Binary don't want to
  depend on.
* put everything related to Units/Modules under GHC.Unit:
  GHC.Unit.Finder, GHC.Unit.Module.{ModGuts,ModIface,Deps,etc.}
* Created several modules under GHC.Types: GHC.Types.Fixity, SourceText,
  etc.
* Split GHC.Utils.Error (into GHC.Types.Error)
* Finally removed GHC.Driver.Types

Note that this patch doesn't put loaded plugins into HscEnv. It's left
for another patch.

Bump haddock submodule

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

Update Haddock submodule

Metric Increase:
   haddock.compiler

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

Update Haddock submodule

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

Update Haddock submodule

Metric Increase:
   haddock.compiler

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

submodule updates: nofib, haddock

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

Add GHC.Hs module hierarchy replacing hsSyn.

Metric Increase:
    haddock.compiler

Daniel Gröber (dxld) authored 6 years ago and Ben Gamari committed 6 years ago

This allows tooling using the GHC API to use plugins internally.
Hopefully this will make it possible to decouple the development of
useful plugins from (currently) kitchen-sink type tooling projects
such as ghc-mod or HIE -- at least to some extent.

Test Plan: validate

Reviewers: bgamari, mpickering

Subscribers: mpickering, alanz, rwbarton, carter

GHC Trac Issues: #15826

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