| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In some cases, the layout of the LANGUAGE/OPTIONS_GHC lines has been
reorganized, while following the convention, to
- place `{-# LANGUAGE #-}` pragmas at the top of the source file, before
any `{-# OPTIONS_GHC #-}`-lines.
- Moreover, if the list of language extensions fit into a single
`{-# LANGUAGE ... -#}`-line (shorter than 80 characters), keep it on one
line. Otherwise split into `{-# LANGUAGE ... -#}`-lines for each
individual language extension. In both cases, try to keep the
enumeration alphabetically ordered.
(The latter layout is preferable as it's more diff-friendly)
While at it, this also replaces obsolete `{-# OPTIONS ... #-}` pragma
occurences by `{-# OPTIONS_GHC ... #-}` pragmas.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The basic idea here is simple, and described in Note [The interactive package]
in HscTypes, which starts thus:
Note [The interactive package]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Type and class declarations at the command prompt are treated as if
they were defined in modules
interactive:Ghci1
interactive:Ghci2
...etc...
with each bunch of declarations using a new module, all sharing a
common package 'interactive' (see Module.interactivePackageId, and
PrelNames.mkInteractiveModule).
This scheme deals well with shadowing. For example:
ghci> data T = A
ghci> data T = B
ghci> :i A
data Ghci1.T = A -- Defined at <interactive>:2:10
Here we must display info about constructor A, but its type T has been
shadowed by the second declaration. But it has a respectable
qualified name (Ghci1.T), and its source location says where it was
defined.
So the main invariant continues to hold, that in any session an original
name M.T only refers to oe unique thing. (In a previous iteration both
the T's above were called :Interactive.T, albeit with different uniques,
which gave rise to all sorts of trouble.)
This scheme deals nicely with the original problem. It allows us to
eliminate a couple of grotseque hacks
- Note [Outputable Orig RdrName] in HscTypes
- Note [interactive name cache] in IfaceEnv
(both these comments have gone, because the hacks they describe are no
longer necessary). I was also able to simplify Outputable.QueryQualifyName,
so that it takes a Module/OccName as args rather than a Name.
However, matters are never simple, and this change took me an
unreasonably long time to get right. There are some details in
Note [The interactive package] in HscTypes.
|
| |
|
|
|
| |
Authored-by: Gergely Risko <gergely@risko.hu>
Signed-off-by: Austin Seipp <austin@well-typed.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit exposes GHC's internal compiler pipeline through a `Hooks`
module in the GHC API. It currently allows you to hook:
* Foreign import/exports declarations
* The frontend up to type checking
* The one shot compilation mode
* Core compilation, and the module iface
* Linking and the phases in DriverPhases.hs
* Quasiquotation
Authored-by: Luite Stegeman <stegeman@gmail.com>
Authored-by: Edsko de Vries <edsko@well-typed.com>
Signed-off-by: Austin Seipp <austin@well-typed.com>
|
| | |
|
| |
|
|
| |
that it can be used, without its rules and instances affecting (and being linked from!) the module being compiled.
|
| | |
|
| |
|
|
| |
I also tidied up the interfaces for LoadIface to be a bit simpler
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
linking scenarios. We weren't searching for .a archives to satisfy
-lfoo options on the GHCi command line, for example.
I've tidied up the code in this module so that dealing with -l options
on the command line is consistent with the handling of extra-libraries
for packages.
While I was here I moved some stuff out of Linker.hs that didn't seem
to belong here: dataConInfoPtrToName (now in new module DebuggerUtils)
and lessUnsafeCoerce (now in DynamicLoading, next to its only use)
|
|
|
This patch was originally developed by Max Bolingbroke, and worked on
further by Austin Seipp. It allows you to write a Core-to-Core pass
and have it dynamically linked into an otherwise-unmodified GHC, and
run at a place you specify in the Core optimisation pipeline.
Main components:
- CoreMonad: new types Plugin, PluginPass
plus a new constructor CoreDoPluginPass in CoreToDo
- SimplCore: stuff to dynamically load any plugins, splice
them into the core-to-core pipeline, and invoke them
- Move "getCoreToDo :: DynFlags -> [CoreToDo]"
which constructs the main core-to-core pipeline
from CoreMonad to SimplCore
SimplCore is the driver for the optimisation pipeline, and it
makes more sense to have the pipeline construction in the driver
not in the infrastructure module.
- New module DynamicLoading: invoked by SimplCore to load any plugins
Some consequential changes in Linker.
- New module GhcPlugins: this should be imported by plugin modules; it
it not used by GHC itself.
|
