summaryrefslogtreecommitdiff
path: root/compiler/iface
Commit message (Collapse)AuthorAgeFilesLines
* De-tabify and remove trailing whitespaceSimon Peyton Jones2014-09-262-231/+219
|
* [ci skip] iface: detabify/dewhitespace IfaceSynAustin Seipp2014-09-251-46/+40
| | | | Signed-off-by: Austin Seipp <austin@well-typed.com>
* `M-x delete-trailing-whitespace` & `M-x untabify`Herbert Valerio Riedel2014-09-241-1/+1
|
* Export `Monoid(..)`/`Foldable(..)`/`Traversable(..)` from PreludeHerbert Valerio Riedel2014-09-211-0/+2
| | | | | | | | | | | | | | | This finally exposes also the methods of these 3 classes in the Prelude in order to allow to define basic class instances w/o needing imports. This almost completes the primary goal of #9586 NOTE: `fold`, `foldl'`, `foldr'`, and `toList` are not exposed yet, as they require upstream fixes for at least `containers` and `bytestring`, and are not required for defining basic instances. Reviewed By: ekmett, austin Differential Revision: https://phabricator.haskell.org/D236
* Make Applicative a superclass of MonadAustin Seipp2014-09-093-31/+35
| | | | | | | | | | | | | | | | | | | | | 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
* Add -fspecialise-aggressivelySimon Peyton Jones2014-08-281-1/+22
| | | | | | | | | | This flag specialises any imported overloaded function that has an unfolding, whether or not it was marked INLINEABLE. We get a lot of orphan SPEC rules as a result, but that doesn't matter provided we don't treat orphan auto-generated rules as causing the module itself to be an orphan module. See Note [Orphans and auto-generated rules] in MkIface.
* Refactor unfoldingsSimon Peyton Jones2014-08-282-7/+9
| | | | | | | | | | | | | | | | | | | | There are two main refactorings here 1. Move the uf_arity field out of CoreUnfolding into UnfWhen It's a lot tidier there. If I've got this right, no behaviour should change. 2. Define specUnfolding and use it in DsBinds and Specialise a) commons-up some shared code b) makes sure that Specialise correctly specialises DFun unfoldings (which it didn't before) The two got put together because both ended up interacting in the specialiser. They cause zero difference to nofib.
* Comments and white spaceSimon Peyton Jones2014-08-071-1/+1
|
* 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-213-12/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Entirely re-jig the handling of default type-family instances (fixes Trac #9063)Simon Peyton Jones2014-07-153-55/+70
| | | | | | | | | | | | | | | | | | | | | | | | | | | In looking at Trac #9063 I decided to re-design the default instances for associated type synonyms. Previously it was all jolly complicated, to support generality that no one wanted, and was arguably undesirable. Specifically * The default instance for an associated type can have only type variables on the LHS. (Not type patterns.) * There can be at most one default instances declaration for each associated type. To achieve this I had to do a surprisingly large amount of refactoring of HsSyn, specifically to parameterise HsDecls.TyFamEqn over the type of the LHS patterns. That change in HsDecls has a (trivial) knock-on effect in Haddock, so this commit does a submodule update too. The net result is good though. The code is simpler; the language specification is simpler. Happy days. Trac #9263 and #9264 are thereby fixed as well.
* Fix #9245 by always checking hi-boot for consistency if we find one.Edward Z. Yang2014-06-281-16/+24
| | | | | | | | | | | | | | | | | | | | | | Summary: What this fix does is reorder how we look for hi-boot files: we unconditionally check for an hi-boot file, and if we don't find one, we check the import graph to see if there was circularity. This is as opposed to the previous scheme (check for circularity, then load hi-boot file). This costs us an extra file system access every typecheck, which is not the best. Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu> Test Plan: Validate and check for compiler regressions in nofib Reviewers: simonpj, austin Subscribers: simonmar, relrod, carter Differential Revision: https://phabricator.haskell.org/D30
* Improve IfaceSyn a bit furtherSimon Peyton Jones2014-06-123-732/+796
| | | | | | | | | | | | | | | | | | | This patch has three main bits: * The most substantial change is that IfaceConDecl no longer records its universal type variables, because they are always the same as those of the parent TyCon. A bit less fuss and clutter. * Add a synonym for IfTopBndr = OccName, and explain why it's an OccName not a FastString * Make the ifMinDef field be a (BooleanFormula IfLclName) rather than (BooleanFormula OccName). These really are occurrences (not binders), and should be treated like other occurences. The first and third change the format of interface files, so you'll need to recompile.
* Fix tyConToIfaceDecl (Trac #9190)Simon Peyton Jones2014-06-111-31/+36
| | | | | | | | | | | | | | | | | | | | | | | There are three bugs here, one serious * We were failing to tidy the type arguments in an IfTyConParent This is what was causing Trac #9190. * toIfaceTcArgs is careful to suppress kind arguments, but there was a clone, tidyToIfaceTcArgs in IfaceSyn which didn't. Now the latter goes via the former. * When pretty-printing a IfaceDecl for an algebraic data type, and doing so in Haskell-98 syntax, we were silently assuming that the universal type variables of the TyCon and the DataCon were the same. But that has not been true for some time. Result: a very confusing display. Solution: during the conversion to IfaceSyn, take the opportunity to make the universal type variables line up exactly. This is very easy to do, makes the pretty-printing easy, and leaves open the future possiblity of not serialising the universal type variables of the data constructor.
* Typo in variable name, no functional changeGabor Greif2014-06-111-2/+2
|
* Better warning message for orphan instances (Ticket #9178)Dr. Heinrich Hördegen2014-06-091-0/+7
| | | | Including a test case.
* Pretty-print built in synonym families in interfacesJoachim Breitner2014-06-073-1/+8
| | | | This closes #9181.
* Make the matcher and wrapper Ids in PatSyn into LocalIds, not GlobalIdsSimon Peyton Jones2014-06-061-3/+1
| | | | | | | | | | | | | | | | | | | | This was a serious bug, exposed by Trac #9175. The matcher and wrapper must be LocalIds, like record selectors and dictionary functions, for the reasons now documented in Note [Exported LocalIds] in Id.lhs In fixing this I found - PatSyn should have an Id inside it (apart from the wrapper and matcher) It should be a Name. Hence psId --> psName, with knock-on consequences - Tidying of PatSyns in TidyPgm was wrong - The keep-alive set in Desugar.deSugar (now) doesn't need pattern synonyms in it I also cleaned up the interface to PatSyn a little, so there's a tiny knock-on effect in Haddock; hence the haddock submodule update. It's very hard to make a test for this bug, so I haven't.
* Comments only (related to Trac #7730)Simon Peyton Jones2014-06-031-0/+2
|
* Use IfLclName instead of OccName in IfaceEqSpecSimon Peyton Jones2014-06-034-9/+8
| | | | | | The type variables in the IfaceEqSpec of a data constructor are really ordinarly *occurrences*, so they should be IfLclNames just like any other type variable occurence.
* Do pretty-printing of TyThings via IfaceDecl (Trac #7730)Simon Peyton Jones2014-06-035-409/+907
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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!
* Just formattingSimon Marlow2014-05-301-9/+17
|
* s/implict/implicit/iEdward Z. Yang2014-05-291-5/+5
| | | | Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
* Assert that matcher-derived PatSyn types match the (redundant) stored types ↵Dr. ERDI Gergo2014-05-271-7/+12
| | | | in IfacePatSyn
* Store IfExtNames for PatSyn matchers and wrappers in interface file.Dr. ERDI Gergo2014-05-275-101/+59
| | | | | | | 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-157-3/+13
| | | | | | | | | | | | | | | | | | 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.
* Refactor buildClass and mkDictSelId a bit, to avoid the no_unf argumentSimon Peyton Jones2014-05-082-11/+6
| | | | | No change in functionality, just a cleaner story, with the RHS for dictionary selectors being treated less specially than before.
* Remove external coreAustin Seipp2014-05-031-34/+1
| | | | Signed-off-by: Austin Seipp <austin@well-typed.com>
* Simplify and tidy up the handling of tuple namesSimon Peyton Jones2014-04-041-16/+24
| | | | | | | | | | | | | This fixes Trac #8954. There were actually three places where tuple occ-names were parsed: - IfaceEnv.lookupOrigNameCache - Convert.isBuiltInOcc - OccName.isTupleOcc_maybe I combined all three into TysWiredIn.isBuiltInOcc_maybe Much nicer.
* Remove redundant compatibility check.Richard Eisenberg2014-03-221-2/+1
| | | | | | Previously, the closed type family compatibility check was done even when type-checking an interface file. But interface files now store compatibility info, so this check was redundant.
* Comments only -- clarifying Notes around compatibility.Richard Eisenberg2014-03-221-1/+1
|
* Use prefix notation in pprIfaceDecl for IfaceIdsDr. ERDI Gergo2014-03-141-1/+1
|
* Honor Op_PrintExplicitForalls setting in pprIfaceForAllPartDr. ERDI Gergo2014-03-141-2/+7
|
* Pretty-print the following TyThings via their IfaceDecl counterpart:Dr. ERDI Gergo2014-03-132-2/+10
| | | | | | * AnId * ACoAxiom * AConLike
* pprIfaceDecl for IfacePatSyn: use pprPatSynSigDr. ERDI Gergo2014-03-131-15/+11
|
* pprIfaceContextArr: print a context including the "=>" arrowDr. ERDI Gergo2014-03-132-9/+9
|
* Cleaned up Maybes.lhsBaldur Blöndal2014-02-131-1/+1
|
* Implement pattern synonymsDr. ERDI Gergo2014-01-205-8/+214
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch implements Pattern Synonyms (enabled by -XPatternSynonyms), allowing y ou to assign names to a pattern and abstract over it. The rundown is this: * Named patterns are introduced by the new 'pattern' keyword, and can be either *unidirectional* or *bidirectional*. A unidirectional pattern is, in the simplest sense, simply an 'alias' for a pattern, where the LHS may mention variables to occur in the RHS. A bidirectional pattern synonym occurs when a pattern may also be used in expression context. * Unidirectional patterns are declared like thus: pattern P x <- x:_ The synonym 'P' may only occur in a pattern context: foo :: [Int] -> Maybe Int foo (P x) = Just x foo _ = Nothing * Bidirectional patterns are declared like thus: pattern P x y = [x, y] Here, P may not only occur as a pattern, but also as an expression when given values for 'x' and 'y', i.e. bar :: Int -> [Int] bar x = P x 10 * Patterns can't yet have their own type signatures; signatures are inferred. * Pattern synonyms may not be recursive, c.f. type synonyms. * Pattern synonyms are also exported/imported using the 'pattern' keyword in an import/export decl, i.e. module Foo (pattern Bar) where ... Note that pattern synonyms share the namespace of constructors, so this disambiguation is required as a there may also be a 'Bar' type in scope as well as the 'Bar' pattern. * The semantics of a pattern synonym differ slightly from a typical pattern: when using a synonym, the pattern itself is matched, followed by all the arguments. This means that the strictness differs slightly: pattern P x y <- [x, y] f (P True True) = True f _ = False g [True, True] = True g _ = False In the example, while `g (False:undefined)` evaluates to False, `f (False:undefined)` results in undefined as both `x` and `y` arguments are matched to `True`. For more information, see the wiki: https://ghc.haskell.org/trac/ghc/wiki/PatternSynonyms https://ghc.haskell.org/trac/ghc/wiki/PatternSynonyms/Implementation Reviewed-by: Simon Peyton Jones <simonpj@microsoft.com> Signed-off-by: Austin Seipp <austin@well-typed.com>
* Re-work the naming story for the GHCi prompt (Trac #8649)Simon Peyton Jones2014-01-091-13/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* 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.
* Rename topDmdType to nopDmdTypeJoachim Breitner2013-12-091-1/+1
| | | | | | | | | because topDmdType is ''not'' the top of the lattice, as it puts an implicit absent demand on free variables, but Abs is the bottom of the Usage lattice. Why nopDmdType? Becuase it is the demand of doing nothing: Everything lazy, everything absent, no definite divergence.
* Turn NameCacheUpdater into a newtypePatrick Palka2013-11-121-1/+1
|
* Fix marshalling of IfaceAt to and from interface filesSimon Peyton Jones2013-11-052-2/+5
| | | | | | I had forgotten about Note [CoAxBranch type variables] in CoAxiom This patch fixes Trac #8500
* Improve pretty printing of IfaceAT in interface filesSimon Peyton Jones2013-11-051-4/+7
|
* 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
* Trailing whitespace onlySimon Peyton Jones2013-10-181-108/+108
|
* When de-serialising interfaces, need to distinguish types from kindsSimon Peyton Jones2013-10-181-10/+37
| | | | | | | | | | | This patches fixes two separate instances of the bug, * one in tc_ax_branches (Trac #8449) * one in type/kind applications in IfaceExpr (hence the new tcIfaceApps) The latter was reported by Iavor, no ticket
* Improve pretty-printing of IfaceSyn type familiesSimon Peyton Jones2013-10-041-15/+14
|
View Lorry Controller Status