summaryrefslogtreecommitdiff
path: root/compiler/main/DynamicLoading.hs
Commit message (Collapse)AuthorAgeFilesLines
* Abort the build when a Core plugin pass is specified in stage1 compilerÖmer Sinan Ağacan2016-06-171-0/+23
| | | | | | | | | | | | | | | | | | | This also makes the behavior the same with frontend plugin errors -- frontend was failing with an exception (`CmdLineError`) while the simplifier was just ignoring plugins. Now we abort with `CmdLineError` in both cases with a slightly improved error message. Test Plan: - add tests (will add tests once #12197 is implemented) - validate (done) Reviewers: austin, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2334 GHC Trac Issues: #11690
* Replace calls to `ptext . sLit` with `text`Jan Stolarek2016-01-181-13/+14
| | | | | | | | | | | | | | | | | | | | Summary: In the past the canonical way for constructing an SDoc string literal was the composition `ptext . sLit`. But for some time now we have function `text` that does the same. Plus it has some rules that optimize its runtime behaviour. This patch takes all uses of `ptext . sLit` in the compiler and replaces them with calls to `text`. The main benefits of this patch are clener (shorter) code and less dependencies between module, because many modules now do not need to import `FastString`. I don't expect any performance benefits - we mostly use SDocs to report errors and it seems there is little to be gained here. Test Plan: ./validate Reviewers: bgamari, austin, goldfire, hvr, alanz Subscribers: goldfire, thomie, mpickering Differential Revision: https://phabricator.haskell.org/D1784
* Implement -hide-all-plugin-packages and -plugin-package(-id), fixing #11244Edward Z. Yang2015-12-221-4/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The basic idea is that we have a new set of "exposed modules" which are /only/ used for plugins, i.e. -fplugin Foo and --frontend Foo. You can interact with this namespace using the flags -plugin-package-id and -plugin-package. By default, this namespace contains all modules in the user namespace (as before), but you can toggle that using -hide-all-plugin-packages. There is one nasty hack: GhcMake respects -fplugin in GHC_OPTIONS to make local plugins work correctly. It also bails out of you have an import of a module which doesn't exist locally or in the package database. The upshot is that we need to be sure to check in the plugin modules too, so we don't give a spurious failure when a plugin is in the plugin namespace but not the main namespace. A better way to fix this would be to distinguish between plugin and normal dependencies in ModSummary. I cheated a little and tweaked a few existing plugins tests to exercise the new code paths. TODO: Documentation Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu> Test Plan: validate Reviewers: bgamari, austin, simonpj, duncan Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1661 GHC Trac Issues: #11244
* Remote GHCi, -fexternal-interpreterSimon Marlow2015-12-171-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: (Apologies for the size of this patch, I couldn't make a smaller one that was validate-clean and also made sense independently) (Some of this code is derived from GHCJS.) This commit adds support for running interpreted code (for GHCi and TemplateHaskell) in a separate process. The functionality is experimental, so for now it is off by default and enabled by the flag -fexternal-interpreter. Reaosns we want this: * compiling Template Haskell code with -prof does not require building the code without -prof first * when GHC itself is profiled, it can interpret unprofiled code, and the same applies to dynamic linking. We would no longer need to force -dynamic-too with TemplateHaskell, and we can load ordinary objects into a dynamically-linked GHCi (and vice versa). * An unprofiled GHCi can load and run profiled code, which means it can use the stack-trace functionality provided by profiling without taking the performance hit on the compiler that profiling would entail. Amongst other things; see https://ghc.haskell.org/trac/ghc/wiki/RemoteGHCi for more details. Notes on the implementation are in Note [Remote GHCi] in the new module compiler/ghci/GHCi.hs. It probably needs more documenting, feel free to suggest things I could elaborate on. Things that are not currently implemented for -fexternal-interpreter: * The GHCi debugger * :set prog, :set args in GHCi * `recover` in Template Haskell * Redirecting stdin/stdout for the external process These are all doable, I just wanted to get to a working validate-clean patch first. I also haven't done any benchmarking yet. I expect there to be slight hit to link times for byte code and some penalty due to having to serialize/deserialize TH syntax, but I don't expect it to be a serious problem. There's also lots of low-hanging fruit in the byte code generator/linker that we could exploit to speed things up. Test Plan: * validate * I've run parts of the test suite with EXTRA_HC_OPTS=-fexternal-interpreter, notably tests/ghci and tests/th. There are a few failures due to the things not currently implemented (see above). Reviewers: simonpj, goldfire, ezyang, austin, alanz, hvr, niteria, bgamari, gibiansky, luite Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1562
* Frontend plugins.Edward Z. Yang2015-12-121-6/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Frontend plugins enable users to write plugins to replace GHC major modes. E.g. instead of saying ghc --make A B C a user can now say ghc --frontend GHC.Frontend.Shake A B C which might provide an alternative implementation of a multi-module build. For more details, see the manual entry. Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu> Test Plan: validate Reviewers: simonmar, bgamari, austin, simonpj Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1598 GHC Trac Issues: #11194
* Add kind equalities to GHC.Richard Eisenberg2015-12-111-4/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This implements the ideas originally put forward in "System FC with Explicit Kind Equality" (ICFP'13). There are several noteworthy changes with this patch: * We now have casts in types. These change the kind of a type. See new constructor `CastTy`. * All types and all constructors can be promoted. This includes GADT constructors. GADT pattern matches take place in type family equations. In Core, types can now be applied to coercions via the `CoercionTy` constructor. * Coercions can now be heterogeneous, relating types of different kinds. A coercion proving `t1 :: k1 ~ t2 :: k2` proves both that `t1` and `t2` are the same and also that `k1` and `k2` are the same. * The `Coercion` type has been significantly enhanced. The documentation in `docs/core-spec/core-spec.pdf` reflects the new reality. * The type of `*` is now `*`. No more `BOX`. * Users can write explicit kind variables in their code, anywhere they can write type variables. For backward compatibility, automatic inference of kind-variable binding is still permitted. * The new extension `TypeInType` turns on the new user-facing features. * Type families and synonyms are now promoted to kinds. This causes trouble with parsing `*`, leading to the somewhat awkward new `HsAppsTy` constructor for `HsType`. This is dispatched with in the renamer, where the kind `*` can be told apart from a type-level multiplication operator. Without `-XTypeInType` the old behavior persists. With `-XTypeInType`, you need to import `Data.Kind` to get `*`, also known as `Type`. * The kind-checking algorithms in TcHsType have been significantly rewritten to allow for enhanced kinds. * The new features are still quite experimental and may be in flux. * TODO: Several open tickets: #11195, #11196, #11197, #11198, #11203. * TODO: Update user manual. Tickets addressed: #9017, #9173, #7961, #10524, #8566, #11142. Updates Haddock submodule.
* Revert "Revert "Revert "Support for multiple signature files in scope."""Edward Z. Yang2015-09-211-16/+5
| | | | This reverts commit 214596de224afa576a9c295bcf53c6941d6892e0.
* Revert "Revert "Support for multiple signature files in scope.""Edward Z. Yang2015-07-201-5/+16
| | | | | | | This reverts commit bac927b9770ff769128b66d13a3e72bf5a9bc514. As it turns out, we need these commits for separate compilation and accurate dependency tracking. So back in they go!
* Revert "Support for multiple signature files in scope."Edward Z. Yang2015-06-111-16/+5
| | | | This reverts commit a7524eaed33324e2155c47d4a705bef1d70a2b5b.
* Refactor RdrName.Provenance, to fix #7672Simon Peyton Jones2015-06-031-3/+3
| | | | | | | | | | | Trac #7672 has a data type T in module A that is in scope *both* locally-bound *and* imported (with a qualified) name. The Provenance of a GlobalRdrElt simply couldn't express that before. Now you can. In doing so, I flattened out Provenance into GlobalRdrElt, so quite a lot of modules are touched in a not-very-interesting way.
* Support for multiple signature files in scope.Edward Z. Yang2015-04-071-5/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: A common pattern when programming with signatures is to combine multiple signatures together (signature linking). We achieve this by making it not-an-error to have multiple, distinct interface files for the same module name, as long as they have the same backing implementation. When a user imports a module name, they get ALL matching signatures dumped into their scope. On the way, I refactored the module finder code, which now distinguishes between exact finds (when you had a 'Module') and regular finds (when you had a 'ModuleName'). I also refactored the package finder code to use a Monoid instance on LookupResult to collect together various results. ToDo: At the moment, if a signature is declared in the local package, it completely overrides any remote signatures. Eventually, we'll want to also pull in the remote signatures (or even override the local signature, if the full implementation is available.) There are bunch of ToDos in the code for what to do once this is done. ToDo: At the moment, whenever a module name lookup occurs in GHCi and we would have seen a signature, we instead continue and return the Module for the backing implementation. This is correct for most cases, but there might be some situations where we want something a little more fine-grained (e.g. :browse should only list identifiers which are available through the in-scope signatures, and not ALL of them.) Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu> Test Plan: validate Reviewers: simonpj, hvr, austin Subscribers: carter, thomie Differential Revision: https://phabricator.haskell.org/D790 GHC Trac Issues: #9252
* Amend TcPluginM interfaceAdam Gundry2014-12-181-4/+10
| | | | | | | | | | | | | | | | | | | | | Summary: Expose some new functions in TcPluginM and remove one, in the light of experience writing plugins. In particular, I've removed lookupRdrName because using it to import modules containing instances leads to subtle bugs; I've expanded on the lookupRdrNameInModuleForPlugins comments. Test Plan: validate Reviewers: simonpj, austin Reviewed By: austin Subscribers: goldfire, ezyang, carter, thomie, yav, gridaphobe Differential Revision: https://phabricator.haskell.org/D553 Conflicts: compiler/typecheck/TcSMonad.hs
* Implement typechecker pluginsAdam Gundry2014-11-201-2/+47
| | | | | | | | | | | | | | | | | | | | Summary: See https://ghc.haskell.org/trac/ghc/wiki/Plugins/TypeChecker This is based on work by Iavor Diatchki and Eric Seidel. Test Plan: validate Reviewers: simonpj, austin Reviewed By: austin Subscribers: gridaphobe, yav, thomie, carter Differential Revision: https://phabricator.haskell.org/D489 Conflicts: docs/users_guide/7.10.1-notes.xml
* Add LANGUAGE pragmas to compiler/ source filesHerbert Valerio Riedel2014-05-151-0/+2
| | | | | | | | | | | | | | | | | | 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.
* Re-work the naming story for the GHCi prompt (Trac #8649)Simon Peyton Jones2014-01-091-11/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Clean up some outdated comments (#8418)Austin Seipp2013-10-091-3/+6
| | | | | Authored-by: Gergely Risko <gergely@risko.hu> Signed-off-by: Austin Seipp <austin@well-typed.com>
* Restructure compilation pipeline to allow hooksAustin Seipp2013-09-221-6/+17
| | | | | | | | | | | | | | | | 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>
* Change a few throwGhcException uses to throwGhcExceptionIOIan Lynagh2013-01-301-2/+2
|
* When using a GHC plugin, load its interface file very partially: just enough ↵Daniel Vainsencher2012-12-051-4/+3
| | | | that it can be used, without its rules and instances affecting (and being linked from!) the module being compiled.
* Pass DynFlags down to showSDocIan Lynagh2012-06-121-10/+11
|
* Refactor to replace hscGetModuleExports by hscGetModuleInterfaceSimon Peyton Jones2011-08-031-15/+15
| | | | I also tidied up the interfaces for LoadIface to be a bit simpler
* Fix #5289 (loading libstdc++.so in GHCi), and also fix some otherSimon Marlow2011-08-031-1/+20
| | | | | | | | | | | | | 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)
* Add dynamically-linked plugins (see Trac #3843)Simon Peyton Jones2011-06-161-0/+150
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.
View Lorry Controller Status