summaryrefslogtreecommitdiff
path: root/compiler/main/GHC.hs
Commit message (Collapse)AuthorAgeFilesLines
* Make PackageState an abstract type.Edward Z. Yang2014-08-051-1/+3
| | | | | | | | | | | | Summary: Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu> Test Plan: validate Reviewers: simonpj, simonmar, hvr, austin Subscribers: simonmar, relrod, ezyang, carter Differential Revision: https://phabricator.haskell.org/D107
* Module reexports, fixing #8407.Edward Z. Yang2014-07-251-5/+7
| | | | | | | | | | | | | | | | | | | | | | | | | The general approach is to add a new field to the package database, reexported-modules, which considered by the module finder as possible module declarations. Unlike declaring stub module files, multiple reexports of the same physical package at the same name do not result in an ambiguous import. Has submodule updates for Cabal and haddock. NB: When a reexport renames a module, that renaming is *not* accessible from inside the package. This is not so much a deliberate design choice as for implementation expediency (reexport resolution happens only when a package is in the package database.) TODO: Error handling when there are duplicate reexports/etc is not very well tested. Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu> Conflicts: compiler/main/HscTypes.lhs testsuite/.gitignore utils/haddock
* Rename PackageId to PackageKey, distinguishing it from Cabal's PackageId.Edward Z. Yang2014-07-211-8/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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!
* 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.
* Remove external coreAustin Seipp2014-05-031-39/+1
| | | | Signed-off-by: Austin Seipp <austin@well-typed.com>
* Normalize GHC Trac URLsHerbert Valerio Riedel2014-04-191-1/+1
| | | | | | | | | | | | | | Update several old http://hackage.haskell.org/trac/ghc URLs references to the current http://ghc.haskell.org/trac/ghc URLs. Signed-off-by: Herbert Valerio Riedel <hvr@gnu.org>
* Export runTcInteractive from TcRnDriver, and from GHC (Trac #8878)Simon Peyton Jones2014-03-131-0/+2
|
* Fix ./validate failure due to unused result.Austin Seipp2014-01-271-2/+5
| | | | | | Fallout from 4ade9627608ea0a88450506222bb9afbbcff4294 Signed-off-by: Austin Seipp <austin@well-typed.com>
* Abort when binutils ld is used with dynamic linking on ARMBen Gamari2014-01-271-0/+31
| | | | | | | | | | | The binutils linker on ARM emits unnecessary R_ARM_COPY relocations which breaks tables-next-to-code in dynamically linked modules. This check should be more selective but there is currently no released version where this bug is fixed. See https://sourceware.org/bugzilla/show_bug.cgi?id=16177 and https://ghc.haskell.org/trac/ghc/ticket/4210#comment:29 for details. Signed-off-by: Austin Seipp <austin@well-typed.com>
* Make initGhcMonad call setUnsafeGlobalDynFlagsSimon Peyton Jones2014-01-101-10/+11
| | | | | | | If we don't do this, then in various GHC API scenarios (which use runGhc) with tracing/debugging/ASSERTs on, we try to read those unsafe global dynamic flags and find them uninitialised.
* Don translate UserInterrupt into ExitFailure 1, let it propagateDuncan Coutts2013-11-141-1/+4
| | | | | | | | | | | | | It is important that if a program recieved ^C from the user, and the program terminates as a result, that it exit with SIGINT so that the parent process knows that was the case. For example cabal calling ghc will then be able to tell the difference between it failing and the user interrupting with ^C and report (or not) appropriately. So we should just let the UserInterrupt exception propagate to the top level error handler which will do the right thing. See http://www.cons.org/cracauer/sigint.html
* Load all modules before reporting errors (#8322)Joachim Breitner2013-11-021-3/+3
| | | | | | Instead of reporting only one "module not found"" error. Signed-off-by: Austin Seipp <austin@well-typed.com>
* Restructure compilation pipeline to allow hooksAustin Seipp2013-09-221-1/+0
| | | | | | | | | | | | | | | | 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>
* Revise implementation of overlapping type family instances.Richard Eisenberg2013-06-211-3/+3
| | | | | | | | | | | | | | | | | | | This commit changes the syntax and story around overlapping type family instances. Before, we had "unbranched" instances and "branched" instances. Now, we have closed type families and open ones. The behavior of open families is completely unchanged. In particular, coincident overlap of open type family instances still works, despite emails to the contrary. A closed type family is declared like this: > type family F a where > F Int = Bool > F a = Char The equations are tried in order, from top to bottom, subject to certain constraints, as described in the user manual. It is not allowed to declare an instance of a closed family.
* Remove extCoreName from DynFlagsIan Lynagh2013-04-261-3/+5
| | | | We now just pass the filename as an argument
* Remove DynFlags's hscOutName fieldIan Lynagh2013-04-261-3/+3
| | | | We now just pass the output filename as an argument instead
* Implement type family instance support for ":info" (#4175)Patrick Palka2013-03-151-0/+2
| | | | v2: added a couple of comments
* Refactor the pipeline/hsc interactionIan Lynagh2013-03-071-6/+4
| | | | | It would probably still benefit from some tidying up, but it's now much more opaque, with the control flow easier to understand.
* Remove printExceptionAndWarnings (deprecated since 7.2)Ian Lynagh2013-02-201-1/+0
|
* Use throwIO rather than throwIan Lynagh2013-01-301-6/+6
|
* Change a few throwGhcException uses to throwGhcExceptionIOIan Lynagh2013-01-301-2/+2
|
* StaticFlags code cleanup (fixes #7595)Jan Stolarek2013-01-281-3/+2
| | | | | | | | | Function responsible for parsing the static flags, that were spread across two modules (StaticFlags and StaticFlagParser), are now in one file. This is analogous to dynamic flags parsing, which is also contained within a single module. Signed-off-by: David Terei <davidterei@gmail.com>
* Implement overlapping type family instances.Richard Eisenberg2012-12-211-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | An ordered, overlapping type family instance is introduced by 'type instance where', followed by equations. See the new section in the user manual (7.7.2.2) for details. The canonical example is Boolean equality at the type level: type family Equals (a :: k) (b :: k) :: Bool type instance where Equals a a = True Equals a b = False A branched family instance, such as this one, checks its equations in order and applies only the first the matches. As explained in the note [Instance checking within groups] in FamInstEnv.lhs, we must be careful not to simplify, say, (Equals Int b) to False, because b might later unify with Int. This commit includes all of the commits on the overlapping-tyfams branch. SPJ requested that I combine all my commits over the past several months into one monolithic commit. The following GHC repos are affected: ghc, testsuite, utils/haddock, libraries/template-haskell, and libraries/dph. Here are some details for the interested: - The definition of CoAxiom has been moved from TyCon.lhs to a new file CoAxiom.lhs. I made this decision because of the number of definitions necessary to support BranchList. - BranchList is a GADT whose type tracks whether it is a singleton list or not-necessarily-a-singleton-list. The reason I introduced this type is to increase static checking of places where GHC code assumes that a FamInst or CoAxiom is indeed a singleton. This assumption takes place roughly 10 times throughout the code. I was worried that a future change to GHC would invalidate the assumption, and GHC might subtly fail to do the right thing. By explicitly labeling CoAxioms and FamInsts as being Unbranched (singleton) or Branched (not-necessarily-singleton), we make this assumption explicit and checkable. Furthermore, to enforce the accuracy of this label, the list of branches of a CoAxiom or FamInst is stored using a BranchList, whose constructors constrain its type index appropriately. I think that the decision to use BranchList is probably the most controversial decision I made from a code design point of view. Although I provide conversions to/from ordinary lists, it is more efficient to use the brList... functions provided in CoAxiom than always to convert. The use of these functions does not wander far from the core CoAxiom/FamInst logic. BranchLists are motivated and explained in the note [Branched axioms] in CoAxiom.lhs. - The CoAxiom type has changed significantly. You can see the new type in CoAxiom.lhs. It uses a CoAxBranch type to track branches of the CoAxiom. Correspondingly various functions producing and consuming CoAxioms had to change, including the binary layout of interface files. - To get branched axioms to work correctly, it is important to have a notion of type "apartness": two types are apart if they cannot unify, and no substitution of variables can ever get them to unify, even after type family simplification. (This is different than the normal failure to unify because of the type family bit.) This notion in encoded in tcApartTys, in Unify.lhs. Because apartness is finer-grained than unification, the tcUnifyTys now calls tcApartTys. - CoreLinting axioms has been updated, both to reflect the new form of CoAxiom and to enforce the apartness rules of branch application. The formalization of the new rules is in docs/core-spec/core-spec.pdf. - The FamInst type (in types/FamInstEnv.lhs) has changed significantly, paralleling the changes to CoAxiom. Of course, this forced minor changes in many files. - There are several new Notes in FamInstEnv.lhs, including one discussing confluent overlap and why we're not doing it. - lookupFamInstEnv, lookupFamInstEnvConflicts, and lookup_fam_inst_env' (the function that actually does the work) have all been more-or-less completely rewritten. There is a Note [lookup_fam_inst_env' implementation] describing the implementation. One of the changes that affects other files is to change the type of matches from a pair of (FamInst, [Type]) to a new datatype (which now includes the index of the matching branch). This seemed a better design. - The TySynInstD constructor in Template Haskell was updated to use the new datatype TySynEqn. I also bumped the TH version number, requiring changes to DPH cabal files. (That's why the DPH repo has an overlapping-tyfams branch.) - As SPJ requested, I refactored some of the code in HsDecls: * splitting up TyDecl into SynDecl and DataDecl, correspondingly changing HsTyDefn to HsDataDefn (with only one constructor) * splitting FamInstD into TyFamInstD and DataFamInstD and splitting FamInstDecl into DataFamInstDecl and TyFamInstDecl * making the ClsInstD take a ClsInstDecl, for parallelism with InstDecl's other constructors * changing constructor TyFamily into FamDecl * creating a FamilyDecl type that stores the details for a family declaration; this is useful because FamilyDecls can appear in classes but other decls cannot * restricting the associated types and associated type defaults for a * class to be the new, more restrictive types * splitting cid_fam_insts into cid_tyfam_insts and cid_datafam_insts, according to the new types * perhaps one or two more that I'm overlooking None of these changes has far-reaching implications. - The user manual, section 7.7.2.2, is updated to describe the new type family instances.
* Invalidate the ModSummary cache in setSessionDynFlags (#7478)Simon Marlow2012-12-071-0/+27
|
* Replace all uses of ghcError with throwGhcException and purge ghcError.Erik de Castro Lopo2012-11-301-1/+1
|
* fix some typosGabor Greif2012-11-211-2/+2
|
* fix off-by-one-column in showRichTokenStream (#7351)Simon Marlow2012-10-251-1/+1
|
* 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
* Rename DynFlag to GeneralFlagIan Lynagh2012-10-161-1/+1
| | | | | This avoids confusion due to [DynFlag] and DynFlags being completely different types.
* Put the DynFlags in a global variable for tracing; fixes #7304Ian Lynagh2012-10-081-1/+1
| | | | | | | | | This is an ugly kludge to make a DynFlags value available for the 'trace' functions. It may not be the value we really ought to use, but it'll be good enough for the pretty-printer to use. Ideally we'd pass the real DynFlags down to all the trace calls, but this will do for now at least.
* Make a start towards eta-rules and injective familiesSimon Peyton Jones2012-09-181-1/+1
| | | | | | | | | | | | | | | | | | | | * Make Any into a type family (which it should always have been) This is to support the future introduction of eta rules for product types (see email on ghc-users title "PolyKind issue" early Sept 2012) * Add the *internal* data type support for (a) closed type families [so that you can't give type instance for 'Any'] (b) injective type families [because Any is really injective] This amounts to two boolean flags on the SynFamilyTyCon constructor of TyCon.SynTyConRhs. There is some knock-on effect, but all of a routine nature. It remains to offer source syntax for either closed or injective families.
* Fix :issafe command (#7172).David Terei2012-08-231-0/+6
|
* Pass DynFlags down to showSDocIan Lynagh2012-06-121-4/+5
|
* GhcApiError now contains a String, not an SDocIan Lynagh2012-06-121-3/+6
|
* Pass DynFlags down to mk_err_msgIan Lynagh2012-06-121-3/+7
|
* Pass DynFlags to the LogActionIan Lynagh2012-06-111-7/+7
| | | | | | | 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.
* Change how pprPanic worksIan Lynagh2012-06-111-0/+1
| | | | | We now include the String and the SDoc in the exception, and don't flatten them into a String until near the top-level
* Remove some commented out codeIan Lynagh2012-05-291-9/+0
|
* Add experimental GHCi monad.David Terei2012-04-241-0/+20
| | | | | | | | Modification of previous commit: e0e99f9948c1eac82cf69dd3cc30cb068e42d45e Allows setting which monad GHCi runs statements in. Unsupported at this stage.
* Revert "Added ':runmonad' command to GHCi"Simon Peyton Jones2012-04-131-13/+0
| | | | | | | | | | Two problems, for now at any rate a) Breaks the build with lots of errors like No instance for (Show (IO ())) arising from a use of `print' b) Discussion of the approache hasn't converged yet (Simon M had a number of suggestions) This reverts commit eecd7c98c1f079c14d99ed831dff33a48ee45e67.
* Added ':runmonad' command to GHCiDavid Terei2012-04-121-0/+13
| | | | | | | | | This command allows you to lift user stmts in GHCi into an IO monad that implements the GHC.GHCi.GHCiSandboxIO type class. This allows for easy sandboxing of GHCi using :runmonad and Safe Haskell. Longer term it would be nice to allow a more general model for the Monad than GHCiSandboxIO but delaying this for the moment.
* --amendDavid Terei2012-04-041-9/+9
|
* Fix GHC API with respect to safe haskell. (#5989)David Terei2012-04-041-25/+45
| | | | | This fixes haddock so it correctly reports the safe haskell mode of a module.
* GHCi: add :seti, for options that apply only at the prompt (#3217)Simon Marlow2012-03-011-8/+55
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | GHCi now maintains two DynFlags: one that applies to whole modules loaded with :load, and one that applies to things typed at the prompt (expressions, statements, declarations, commands). The :set command modifies both DynFlags. This is for backwards compatibility: users won't notice any difference. The :seti command applies only to the interactive DynFlags. Additionally, I made a few changes to ":set" (with no arguments): * Now it only prints out options that differ from the defaults, rather than the whole list. * There is a new variant, ":set -a" to print out all options (the old behaviour). * It also prints out language options. e.g. Prelude> :set options currently set: none. base language is: Haskell2010 with the following modifiers: -XNoDatatypeContexts -XNondecreasingIndentation GHCi-specific dynamic flag settings: other dynamic, non-language, flag settings: -fimplicit-import-qualified warning settings: ":seti" (with no arguments) does the same as ":set", but for the interactive options. It also has the "-a" option. The interactive DynFlags are kept in the InteractiveContext, and copied into the HscEnv at the appropriate points (all in HscMain). There are some new GHC API operations: -- | Set the 'DynFlags' used to evaluate interactive expressions. setInteractiveDynFlags :: GhcMonad m => DynFlags -> m () -- | Get the 'DynFlags' used to evaluate interactive expressions. getInteractiveDynFlags :: GhcMonad m => m DynFlags -- | Sets the program 'DynFlags'. setProgramDynFlags :: GhcMonad m => DynFlags -> m [PackageId] -- | Returns the program 'DynFlags'. getProgramDynFlags :: GhcMonad m => m DynFlags Note I have not completed the whole of the plan outlined in #3217 yet: when in the context of a loaded module we don't take the interactive DynFlags from that module. That needs some more refactoring and thinking about, because we'll need to save and restore the original interactive DynFlags. This solves the immediate problem that people are having with the new flag checking in 7.4.1, because now it is possible to set language options in ~/.ghci that do not affect loaded modules and thereby cause recompilation.
* Abstract out the hFlush calls in the GHC APIIan Lynagh2012-02-241-4/+5
| | | | | | stdout/stderr might be closed, so we can't just hFlush them. So we instead allow configuration in the same way that log_action is configurable.
* Switch to using the time package, rather than old-timeIan Lynagh2012-01-141-2/+2
|
* Major refactoring of CoAxiomsSimon Peyton Jones2012-01-031-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Fix safe imports to work in GHCi.David Terei2011-12-221-10/+16
|
* Tabs -> SpacesDavid Terei2011-12-191-212/+206
|
View Lorry Controller Status