summaryrefslogtreecommitdiff
path: root/compiler/iface/LoadIface.lhs
Commit message (Collapse)AuthorAgeFilesLines
* compiler: de-lhs iface/Austin Seipp2014-12-031-953/+0
| | | | Signed-off-by: Austin Seipp <austin@well-typed.com>
* Change loadSrcInterface to return a list of ModIfaceEdward Z. Yang2014-11-261-6/+44
| | | | | | | | | | | | | | | | | | | | Summary: This change is in preparation to support signature imports, which may pull in multiple interface files. At the moment, the list always contains only one element, but in a later patch it may contain more. I also adjusted some error reporting code so that it didn't take the full iface, but just whether or not the iface in question was a boot module. Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu> Test Plan: validate Reviewers: simonpj, austin Subscribers: thomie, carter Differential Revision: https://phabricator.haskell.org/D436
* Docs onlyEdward Z. Yang2014-11-171-2/+5
| | | | | | | | | | | | | | Summary: Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu> Test Plan: n/a Reviewers: austin, Mikolaj Reviewed By: austin, Mikolaj Subscribers: thomie, carter Differential Revision: https://phabricator.haskell.org/D446
* Implementation of hsig (module signatures), per #9252Edward Z. Yang2014-10-241-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Module signatures, like hs-boot files, are Haskell modules which omit value definitions and contain only signatures. This patchset implements one particular aspect of module signature, namely compiling them against a concrete implementation. It works like this: when we compile an hsig file, we must be told (via the -sig-of flag) what module this signature is implementing. The signature is compiled into an interface file which reexports precisely the entities mentioned in the signature file. We also verify that the interface is compatible with the implementation. This feature is useful in a few situations: 1. Like explicit import lists, signatures can be used to reduce sensitivity to upstream changes. However, a signature can be defined once and then reused by many modules. 2. Signatures can be used to quickly check if a new upstream version is compatible, by typechecking just the signatures and not the actual modules. 3. A signature can be used to mediate separate modular development, where the signature is used as a placeholder for functionality which is loaded in later. (This is only half useful at the moment, since typechecking against signatures without implementations is not implemented in this patchset.) Unlike hs-boot files, hsig files impose no performance overhead. This patchset punts on the type class instances (and type families) problem: instances simply leak from the implementation to the signature. You can explicitly specify what instances you expect to have, and those will be checked, but you may get more instances than you asked for. Our eventual plan is to allow hiding instances, but to consider all transitively reachable instances when considering overlap and soundness. ToDo: signature merging: when a module is provided by multiple signatures for the same base implementation, we should not consider this ambiguous. ToDo: at the moment, signatures do not constitute use-sites, so if you write a signature for a deprecated function, you won't get a warning when you compile the signature. Future work: The ability to feed in shaping information so that we can take advantage of more type equalities than might be immediately evident. Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu> Test Plan: validate and new tests Reviewers: simonpj, simonmar, hvr, austin Subscribers: simonmar, relrod, ezyang, carter, goldfire Differential Revision: https://phabricator.haskell.org/D130 GHC Trac Issues: #9252
* Make Applicative a superclass of MonadAustin Seipp2014-09-091-13/+13
| | | | | | | | | | | | | | | | | | | | | Summary: This includes pretty much all the changes needed to make `Applicative` a superclass of `Monad` finally. There's mostly reshuffling in the interests of avoid orphans and boot files, but luckily we can resolve all of them, pretty much. The only catch was that Alternative/MonadPlus also had to go into Prelude to avoid this. As a result, we must update the hsc2hs and haddock submodules. Signed-off-by: Austin Seipp <austin@well-typed.com> Test Plan: Build things, they might not explode horribly. Reviewers: hvr, simonmar Subscribers: simonmar Differential Revision: https://phabricator.haskell.org/D13
* Package keys (for linking/type equality) separated from package IDs.Edward Z. Yang2014-08-051-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch set makes us no longer assume that a package key is a human readable string, leaving Cabal free to "do whatever it wants" to allocate keys; we'll look up the PackageId in the database to display to the user. This also means we have a new level of qualifier decisions to make at the package level, and rewriting some Safe Haskell error reporting code to DTRT. Additionally, we adjust the build system to use a new ghc-cabal output Make variable PACKAGE_KEY to determine library names and other things, rather than concatenating PACKAGE/VERSION as before. Adds a new `-this-package-key` flag to subsume the old, erroneously named `-package-name` flag, and `-package-key` to select packages by package key. RFC: The md5 hashes are pretty tough on the eye, as far as the file system is concerned :( ToDo: safePkg01 test had its output updated, but the fix is not really right: the rest of the dependencies are truncated due to the fact the we're only grepping a single line, but ghc-pkg is wrapping its output. ToDo: In a later commit, update all submodules to stop using -package-name and use -this-package-key. For now, we don't do it to avoid submodule explosion. Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu> Test Plan: validate Reviewers: simonpj, simonmar, hvr, austin Subscribers: simonmar, relrod, carter Differential Revision: https://phabricator.haskell.org/D80
* Always qualify on hi interface mismatch.Edward Z. Yang2014-07-211-1/+1
| | | | Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
* Rename PackageId to PackageKey, distinguishing it from Cabal's PackageId.Edward Z. Yang2014-07-211-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Previously, both Cabal and GHC defined the type PackageId, and we expected them to be roughly equivalent (but represented differently). This refactoring separates these two notions. A package ID is a user-visible identifier; it's the thing you write in a Cabal file, e.g. containers-0.9. The components of this ID are semantically meaningful, and decompose into a package name and a package vrsion. A package key is an opaque identifier used by GHC to generate linking symbols. Presently, it just consists of a package name and a package version, but pursuant to #9265 we are planning to extend it to record other information. Within a single executable, it uniquely identifies a package. It is *not* an InstalledPackageId, as the choice of a package key affects the ABI of a package (whereas an InstalledPackageId is computed after compilation.) Cabal computes a package key for the package and passes it to GHC using -package-name (now *extremely* misnamed). As an added bonus, we don't have to worry about shadowing anymore. As a follow on, we should introduce -current-package-key having the same role as -package-name, and deprecate the old flag. This commit is just renaming. The haddock submodule needed to be updated. Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu> Test Plan: validate Reviewers: simonpj, simonmar, hvr, austin Subscribers: simonmar, relrod, carter Differential Revision: https://phabricator.haskell.org/D79 Conflicts: compiler/main/HscTypes.lhs compiler/main/Packages.lhs utils/haddock
* Do pretty-printing of TyThings via IfaceDecl (Trac #7730)Simon Peyton Jones2014-06-031-5/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | All the initial work on this was done fy 'archblob' (fcsernik@gmail.com); thank you! I reviewed the patch, started some tidying, up and then ended up in a huge swamp of changes, not all of which I can remember now. But: * To suppress kind arguments when we have -fno-print-explicit-kinds, - IfaceTyConApp argument types are in a tagged list IfaceTcArgs * To allow overloaded types to be printed with =>, add IfaceDFunTy to IfaceType. * When printing data/type family instances for the user, I've made them print out an informative RHS, which is a new feature. Thus ghci> info T data family T a data instance T Int = T1 Int Int data instance T Bool = T2 * In implementation terms, pprIfaceDecl has just one "context" argument, of type IfaceSyn.ShowSub, which says - How to print the binders of the decl see note [Printing IfaceDecl binders] in IfaceSyn - Which sub-comoponents (eg constructors) to print * Moved FastStringEnv from RnEnv to OccName It all took a ridiculously long time to do. But it's done!
* s/implict/implicit/iEdward Z. Yang2014-05-291-5/+5
| | | | Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
* Store IfExtNames for PatSyn matchers and wrappers in interface file.Dr. ERDI Gergo2014-05-271-1/+2
| | | | | | | This way, the Ids for the matchers/wrappers are reused by importing modules, and thus unfoldings are kept. Also updates haddock submodule to accomodate tweaks in PatSyn representation
* Add LANGUAGE pragmas to compiler/ source filesHerbert Valerio Riedel2014-05-151-0/+1
| | | | | | | | | | | | | | | | | | 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.
* Improve error message when using qualified names in GHCiSimon Peyton Jones2014-01-031-13/+21
| | | | | | | | | | | When you say ghci> :i Foo.x GHCi tries to find module Foo and get 'x' from it. But if Foo doesn't exist we don't want to say: Attempting to use module ‛Foo’ which is not loaded This is a bit confusing. Rather we just want to say that Foo.x is not in scope.
* Add support for module reification (#1480)Austin Seipp2013-11-021-1/+11
| | | | | Authored-by: Gergely Risko <gergely@risko.hu> Signed-off-by: Austin Seipp <austin@well-typed.com>
* Suppress AMP warnings with -XNoImplicitPrelude (fixed Trac #8320)Simon Peyton Jones2013-10-241-4/+21
| | | | | | | | | | The AMP warnings caused 'base' to be loaded even when we were compiling 'ghc-prim'. That is bad, bad, bad. We got a very obscure message attempting to use module ‛ghc-prim:GHC.Types’ (libraries/ghc-prim/./GHC/Types.hs) which is not loaded See Note [Home module load error] in LoadIface
* Restructure compilation pipeline to allow hooksAustin Seipp2013-09-221-1/+4
| | | | | | | | | | | | | | | | 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>
* Remove readIface's unused argumentIan Lynagh2013-03-171-3/+3
|
* Fix -dynamic-too with -boot filesIan Lynagh2013-03-091-1/+2
| | | | | It was looking for Foo.dyn_hi rather than Foo.dyn_hi-boot, and so falling back to the slow way
* Merge branch 'refs/heads/vect-avoid' into vect-avoid-mergeManuel M T Chakravarty2013-02-061-7/+7
|\ | | | | | | | | | | | | | | | | Conflicts: compiler/rename/RnSource.lhs compiler/simplCore/OccurAnal.lhs compiler/vectorise/Vectorise/Exp.hs NB: Merging instead of rebasing for a change. During rebase Git got confused due to the lack of the submodules in my quite old fork.
| * Rewrote vectorisation avoidance (based on the HS paper)Manuel M T Chakravarty2012-12-051-7/+7
| | | | | | | | | | | | | | * Vectorisation avoidance is now the default * Types and values from unvectorised modules are permitted in scalar code * Simplified the VECTORISE pragmas (see http://hackage.haskell.org/trac/ghc/wiki/DataParallel/VectPragma for the spec) * Vectorisation information is now included in the annotated Core AST
* | Change a few throwGhcException uses to throwGhcExceptionIOIan Lynagh2013-01-301-1/+1
| |
* | Implement the -dynamic-too optimised path for the NCGIan Lynagh2012-12-111-15/+13
| | | | | | | | | | | | | | | | We don't yet have the slow path, for when we have to fall back to separate compilation. We also only currently handle the case qhere we're compiling Haskell code with the NCG.
* | Fix loading dynamic interfaces when using -dynamic-tooIan Lynagh2012-12-081-1/+1
| | | | | | | | | | | | | | | | We need to have WayDyn in the ways in the DynFlags, or the interface loader will fail. -dynamic-too now correctly evaluates whether or not it is possible to build for the dynamic way too, but doesn't actually do so yet.
* | Tweaks to dynamic-too codeIan Lynagh2012-12-071-2/+6
| |
* | Merge branch 'master' of mac:ghc/git/val64/.Ian Lynagh2012-12-061-50/+66
|\ \
| * | Add the beginnings of support for building vanilla and dynamic at the same timeIan Lynagh2012-12-051-1/+20
| | |
| * | Refactor findAndReadIface; no functional changesIan Lynagh2012-12-051-50/+47
| | |
* | | When using a GHC plugin, load its interface file very partially: just enough ↵Daniel Vainsencher2012-12-051-36/+56
|/ / | | | | | | that it can be used, without its rules and instances affecting (and being linked from!) the module being compiled.
* | Replace all uses of ghcError with throwGhcException and purge ghcError.Erik de Castro Lopo2012-11-301-1/+1
| |
* | Revert "Move seq's fixity declaration info primops.txt.pp"Ian Lynagh2012-11-231-1/+3
| | | | | | | | | | | | | | This reverts commit eb5196c48480c7dbec25aa175e43b9c20277f29c. For some reason it didn't work, and I don't have time to look into it right now.
* | Move seq's fixity declaration info primops.txt.ppIan Lynagh2012-11-231-3/+1
| |
* | Add fixity information to primops (ticket #6026)Michal Terepeta2012-11-231-2/+4
| |
* | Some alpha renamingIan Lynagh2012-10-161-1/+1
|/ | | | | Mostly d -> g (matching DynFlag -> GeneralFlag). Also renamed if* to when*, matching the Haskell if/when names
* Move -fno-warn-orphan flag into individual modulesIan Lynagh2012-07-151-0/+1
|
* Move and rename opt_HiVersionIan Lynagh2012-06-181-2/+2
| | | | It isn't really an option at all
* Pass DynFlags down to showSDocIan Lynagh2012-06-121-1/+2
|
* Pass DynFlags to the LogActionIan Lynagh2012-06-111-1/+1
| | | | | | | A side-effect is that we can no longer use the LogAction in defaultErrorHandler, as we don't have DynFlags at that point. But all that defaultErrorHandler did is to print Strings as SevFatal, so now it takes a 'FatalMessager' instead.
* Replace printDump with a new SeverityIan Lynagh2012-05-291-1/+3
| | | | | | We now use log_action with severity SevDump, rather than calling printDump. This means that what happens to dumped info is now under the control of the GHC API user, rather than always going to stdout.
* Report deprecations at occurrence sites, not once per moduleSimon Peyton Jones2012-04-251-1/+1
| | | | Fixes Trac #5867, and is generally nicer
* Add a crucial forkM on the superclass context of IfaceClass in tcIfaceDeclSimon Peyton Jones2012-03-281-1/+1
| | | | | | | | | The absence of this was causing a loop when typechecking an interface where the superclass context mentioned an associated type class C (T a) => D a where data T a Fixes Trac #5970
* Remove getDOpts; use getDynFlags insteadIan Lynagh2012-01-191-3/+3
|
* Implememt -fdefer-type-errors (Trac #5624)Simon Peyton Jones2012-01-121-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch implements the idea of deferring (most) type errors to runtime, instead emitting only a warning at compile time. The basic idea is very simple: * The on-the-fly unifier in TcUnify never fails; instead if it gets stuck it emits a constraint. * The constraint solver tries to solve the constraints (and is entirely unchanged, hooray). * The remaining, unsolved constraints (if any) are passed to TcErrors.reportUnsolved. With -fdefer-type-errors, instead of emitting an error message, TcErrors emits a warning, AND emits a binding for the constraint witness, binding it to (error "the error message"), via the new form of evidence TcEvidence.EvDelayedError. So, when the program is run, when (and only when) that witness is needed, the program will crash with the exact same error message that would have been given at compile time. Simple really. But, needless to say, the exercise forced me into some major refactoring. * TcErrors is almost entirely rewritten * EvVarX and WantedEvVar have gone away entirely * ErrUtils is changed a bit: * New Severity field in ErrMsg * Renamed the type Message to MsgDoc (this change touches a lot of files trivially) * One minor change is that in the constraint solver we try NOT to combine insoluble constraints, like Int~Bool, else all such type errors get combined together and result in only one error message! * I moved some definitions from TcSMonad to TcRnTypes, where they seem to belong more
* Major refactoring of CoAxiomsSimon Peyton Jones2012-01-031-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch should have no user-visible effect. It implements a significant internal refactoring of the way that FC axioms are handled. The ultimate goal is to put us in a position to implement "pattern-matching axioms". But the changes here are only does refactoring; there is no change in functionality. Specifically: * We now treat data/type family instance declarations very, very similarly to types class instance declarations: - Renamed InstEnv.Instance as InstEnv.ClsInst, for symmetry with FamInstEnv.FamInst. This change does affect the GHC API, but for the better I think. - Previously, each family type/data instance declaration gave rise to a *TyCon*; typechecking a type/data instance decl produced that TyCon. Now, each type/data instance gives rise to a *FamInst*, by direct analogy with each class instance declaration giving rise to a ClsInst. - Just as each ClsInst contains its evidence, a DFunId, so each FamInst contains its evidence, a CoAxiom. See Note [FamInsts and CoAxioms] in FamInstEnv. The CoAxiom is a System-FC thing, and can relate any two types, whereas the FamInst relates directly to the Haskell source language construct, and always has a function (F tys) on the LHS. - Just as a DFunId has its own declaration in an interface file, so now do CoAxioms (see IfaceSyn.IfaceAxiom). These changes give rise to almost all the refactoring. * We used to have a hack whereby a type family instance produced a dummy type synonym, thus type instance F Int = Bool -> Bool translated to axiom FInt :: F Int ~ R:FInt type R:FInt = Bool -> Bool This was always a hack, and now it's gone. Instead the type instance declaration produces a FamInst, whose axiom has kind axiom FInt :: F Int ~ Bool -> Bool just as you'd expect. * Newtypes are done just as before; they generate a CoAxiom. These CoAxioms are "implicit" (do not generate an IfaceAxiom declaration), unlike the ones coming from family instance declarations. See Note [Implicit axioms] in TyCon On the whole the code gets significantly nicer. There were consequential tidy-ups in the vectoriser, but I think I got them right.
* Tweak to pretty printing for UsageFileSimon Marlow2011-11-181-1/+2
|
* Fix loading VectInfo for type constructorsManuel M T Chakravarty2011-11-141-1/+1
|
* Fix #437: recompilation check includes flagsDavid Terei2011-11-091-0/+1
|
* addDependentFile #4900Greg Weber2011-11-051-0/+2
| | | | | | | | Let GHC know about an external dependency that Template Haskell uses so that GHC can recompile when the dependency changes. No support for ghc -M There is a corresponding addition to the template-haskell library
* Clean up and complete the vectorisation of type classesManuel M T Chakravarty2011-11-041-2/+1
|
* Tabs -> spacesManuel M T Chakravarty2011-10-251-291/+291
|
* move AvailInfo and related things into its own moduleSimon Marlow2011-09-211-0/+1
|