summaryrefslogtreecommitdiff
path: root/compiler/iface
Commit message (Collapse)AuthorAgeFilesLines
* Address #11471 by putting RuntimeRep in kinds.wip/runtime-repRichard Eisenberg2016-02-247-158/+253
| | | | | | | | | | | | | | | | | | | | | See Note [TYPE] in TysPrim. There are still some outstanding pieces in #11471 though, so this doesn't actually nail the bug. This commit also contains a few performance improvements: * Short-cut equality checking of nullary type syns * Compare types before kinds in eqType * INLINE coreViewOneStarKind * Store tycon binders separately from kinds. This resulted in a ~10% performance improvement in compiling the Cabal package. No change in functionality other than performance. (This affects the interface file format, though.) This commit updates the haddock submodule.
* Improve piResultTys and friendsSimon Peyton Jones2016-02-181-1/+1
| | | | | | | | | | | | | | | | | Several things here: * Re-implement piResultTys so that its substitution has the correct in-scope set That means paying close attention to performance, since as we discovered in Trac #11371, it's a heavily used function and is often used on ordinary function types, with no foralls to worry about substituting. * Kill off applyTys, which was just the same as piResultTys. * Re-engineer MkCore.mkCoreApps so that it calls piResultTys, rather than repeatedly calling piResultTy.
* (Another) minor refactoring of substitutionsSimon Peyton Jones2016-02-181-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | No change in functionality here, but greater clarity: * In FamInstEnv.FlattenEnv, kill off the fi_in_scope field We are already maintaining an in-scope set in the fe_subst field, so it's silly do to it twice. (This isn't strictly connected to the rest of this patch, but the nomenclature changes below affect the same code, so I put them together.) * TyCoRep.extendTCVSubst used to take a TyVar or a CoVar and work out what to do, but in fact we almost always know which of the two we are doing. So: - define extendTvSubst, extendCvSubst - and use them * Similar renamings in TyCoRep: - extendTCvSubstList --> extendTvSubstList - extendTCvSubstBinder --> extendTvSubstBinder - extendTCvSubstAndInScope --> extendTvSubstAndInScope * Add Type.extendTvSubstWithClone, extendCvSubstWithClone * Similar nomenclature changes in Subst, SimplEnv, Specialise * Kill off TyCoRep.substTelescope (never used)
* Rename "open" subst functionsBartosz Nitka2016-01-272-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | This is the renaming that @simonpj requested: ``` · zipOpenTCvSubst -> zipTvSubst (It only deals with tyvars) · zipOpenTCvSubstCoVars -> zipCvSubst (it only deals with covars) · zipOpenTCvSubstBinders -> zipTyBinderSubst (it only deals with TyBinders, not covars) ``` plus the `mk` variant. Test Plan: ./validate Reviewers: simonpj, goldfire, austin, bgamari Subscribers: thomie, simonpj Differential Revision: https://phabricator.haskell.org/D1853 GHC Trac Issues: #11371
* Construct in_scope set in mkTopTCvSubstBartosz Nitka2016-01-261-1/+1
| | | | | | | | | | | | | | | | | | | | The pre-condition on `mkTopTCvSubst` turned out to be wrong and not satisfied by any of the callers. I've fixed it, so that it constructs the in_scope set from the range of the substitution. `mkTopTCvSubst` was also unnecessarily general it is never called with `CoVars`, so I changed the type signature and added an assertion. Test Plan: ./validate --slow Reviewers: goldfire, simonpj, bgamari, austin Reviewed By: simonpj Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1801 GHC Trac Issues: #11371
* Kill off zipTopTCvSubst in favour of zipOpenTCvSubstSimon Peyton Jones2016-01-261-3/+3
| | | | | | | | | | | | | | As Bartosz has discovered, the invariants for substitutions were wrong, and in particular the "mkTop...Subst" and "zipTop..Subst" functions were building substitutions that didn't obey even the old invariants. This patch kills of the bogus zipTopTCvSubst in favour of the more robust zipOpenTCvSubst. I tripped over this because my upcoming patch (concerning SetLevels, Trac #11330) triggered an ASSERT failure in the substitution well-formedness assertion in TyCoRep.
* Rework derivation of type representations for wired-in thingsBen Gamari2016-01-201-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously types defined by `GHC.Types` and `GHC.Prim` had their `Typeable` representations manually defined in `GHC.Typeable.Internals`. This was terrible, resulting in a great deal of boilerplate and a number of bugs due to missing or inconsistent representations (see #11120). Here we take a different tack, initially proposed by Richard Eisenberg: We wire-in the `Module`, `TrName`, and `TyCon` types, allowing them to be used in `GHC.Types`. We then allow the usual type representation generation logic to handle this module. `GHC.Prim`, on the other hand, is a bit tricky as it has no object code of its own. To handle this we instead place the type representations for the types defined here in `GHC.Types`. On the whole this eliminates several special-cases as well as a fair amount of boilerplate from hand-written representations. Moreover, we get full coverage of primitive types for free. Test Plan: Validate Reviewers: goldfire, simonpj, austin, hvr Subscribers: goldfire, simonpj, thomie Differential Revision: https://phabricator.haskell.org/D1774 GHC Trac Issues: #11120
* Fix IfaceType generation for TyCons without TyVarsÖmer Sinan Ağacan2016-01-191-1/+7
| | | | | | | | | | | | | - This is only used for printing purposes (in :browse etc.). - Fixes #11266. Reviewers: goldfire, bgamari, austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1799 GHC Trac Issues: #11266
* Check InScopeSet in substTy and provide substTyUncheckedBartosz Nitka2016-01-191-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | This adds sanity checks to `substTy` that implement: > when calling substTy subst ty it should be the case that the in-scope > set in the substitution is a superset of > * The free vars of the range of the substitution > * The free vars of ty minus the domain of the substitution and replaces violators with unchecked version. The violators were found by running the GHC test suite. This ensures that I can work on this incrementally and that what I fix won't be undone by some other change. It also includes a couple of fixes that I've already done. Test Plan: ./validate Reviewers: simonmar, goldfire, simonpj, austin, bgamari Reviewed By: simonpj, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1792 GHC Trac Issues: #11371
* Replace calls to `ptext . sLit` with `text`Jan Stolarek2016-01-185-152/+152
| | | | | | | | | | | | | | | | | | | | 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
* Refactoring on IdInfo and system derived namesSimon Peyton Jones2016-01-181-5/+0
| | | | | | | | | | | | | | | | | | | | Some modest refactoring, triggered in part by Trac #11051 * Kill off PatSynId, ReflectionId in IdDetails They were barely used, and only for pretty-printing * Add helper function Id.mkExportedVanillaId, and use it * Polish up OccName.isDerivedOccName, as a predicate for definitions generated internally by GHC, which we might not want to show to the user. * Kill off unused OccName.mkDerivedTyConOcc * Shorten the derived OccNames for newtype and data instance axioms * A bit of related refactoring around newFamInstAxiomName
* un-wire-in error, undefined, CallStack, and IPEric Seidel2016-01-181-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | I missed a crucial step in the wiring-in process of `CallStack` in D861, the bit where you actually wire-in the Name... This led to a nasty bug where GHC thought `CallStack` was not wired-in and tried to fingerprint it, which failed because the defining module was not loaded. But we don't need `CallStack` to be wired-in anymore since `error` and `undefined` no longer need to be wired-in. So we just remove them all. Updates haddock submodule. Test Plan: `./validate` and `make slowtest TEST=tc198` Reviewers: simonpj, goldfire, austin, hvr, bgamari Reviewed By: simonpj, bgamari Subscribers: goldfire, thomie Projects: #ghc Differential Revision: https://phabricator.haskell.org/D1739 GHC Trac Issues: #11331
* Work SourceText in for all integer literalsAlan Zimmerman2016-01-161-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Certain syntactic elements have integers in them, such as fixity specifications, SPECIALISE pragmas and so on. The lexer will accept mult-radix literals, with arbitrary leading zeros in these. Bring in a SourceText field to each affected AST element to capture the original literal text for use with API Annotations. Affected hsSyn elements are ``` -- See note [Pragma source text] data Activation = NeverActive | AlwaysActive | ActiveBefore SourceText PhaseNum -- Active only *strictly before* this phase | ActiveAfter SourceText PhaseNum -- Active in this phase and later deriving( Eq, Data, Typeable ) -- Eq used in comparing rules in HsDecls data Fixity = Fixity SourceText Int FixityDirection -- Note [Pragma source text] deriving (Data, Typeable) ``` and ``` | HsTickPragma -- A pragma introduced tick SourceText -- Note [Pragma source text] in BasicTypes (StringLiteral,(Int,Int),(Int,Int)) -- external span for this tick ((SourceText,SourceText),(SourceText,SourceText)) -- Source text for the four integers used in the span. -- See note [Pragma source text] in BasicTypes (LHsExpr id) ``` Updates haddock submodule Test Plan: ./validate Reviewers: goldfire, bgamari, austin Reviewed By: bgamari Subscribers: thomie, mpickering Differential Revision: https://phabricator.haskell.org/D1781 GHC Trac Issues: #11430
* Refactor lookupFixityRn-related code following D1744RyanGlScott2016-01-151-7/+7
| | | | | | | | | | | | Test Plan: ./validate Reviewers: goldfire, austin, bgamari, simonpj Subscribers: simonpj, thomie Differential Revision: https://phabricator.haskell.org/D1766 GHC Trac Issues: #11345
* Add missing type representationsBen Gamari2016-01-131-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | Previously we were missing `Typeable` representations for several wired-in types (and their promoted constructors). These include, * `Nat` * `Symbol` * `':` * `'[]` Moreover, some constructors were incorrectly identified as being defined in `GHC.Types` whereas they were in fact defined in `GHC.Prim`. Ultimately this is just a temporary band-aid as there is general agreement that we should eliminate the manual definition of these representations entirely. Test Plan: Validate Reviewers: austin, hvr Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1769 GHC Trac Issues: #11120
* Tiny refactorSimon Peyton Jones2016-01-071-3/+4
|
* Remove unused exportSimon Peyton Jones2016-01-071-1/+1
|
* Drop pre-AMP compatibility CPP conditionalsHerbert Valerio Riedel2015-12-311-3/+0
| | | | | | | | | | | | Since GHC 8.1/8.2 only needs to be bootstrap-able by GHC 7.10 and GHC 8.0 (and GHC 8.2), we can now finally drop all that pre-AMP compatibility CPP-mess for good! Reviewers: austin, goldfire, bgamari Subscribers: goldfire, thomie, erikd Differential Revision: https://phabricator.haskell.org/D1724
* Visible type applicationRichard Eisenberg2015-12-242-6/+11
| | | | | | | | | | | | | This re-working of the typechecker algorithm is based on the paper "Visible type application", by Richard Eisenberg, Stephanie Weirich, and Hamidhasan Ahmed, to be published at ESOP'16. This patch introduces -XTypeApplications, which allows users to say, for example `id @Int`, which has type `Int -> Int`. See the changes to the user manual for details. This patch addresses tickets #10619, #5296, #10589.
* Refactoring onlySimon Peyton Jones2015-12-242-6/+5
| | | | | | | | | | | | | This moves code around to more sensible places. - Construction for CoAxiom is localised in FamInstEnv - orphNamesOfxx moves to CoreFVs - roughMatchTcs, instanceCantMatch moves to Unify - mkNewTypeCo moves from Coercion to FamInstEnv, and is renamed mkNewTypeCoAxiom, which makes more sense
* Fix ASSERT in buildPatSyn, and T10897 testSimon Peyton Jones2015-12-231-6/+10
| | | | This closes Trac #10897
* Random typo fixesHerbert Valerio Riedel2015-12-171-1/+1
| | | | [skip ci]
* Improve pretty-printing in pprIfaceIdBndrSimon Peyton Jones2015-12-171-1/+1
| | | | In particular, add parnes when we need an explicit type.
* Add kind equalities to GHC.Richard Eisenberg2015-12-118-571/+806
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Make the order of fixities in the iface file deterministicBartosz Nitka2015-12-021-1/+5
| | | | | | | | | | | | | | | | | This normalizes the order of written fixities by sorting by `OccName` making it independent of `Unique` order. Test Plan: I've added a new testcase Reviewers: austin, bgamari, simonmar Reviewed By: simonmar Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1557 GHC Trac Issues: #4012
* Refactor treatment of wildcardsSimon Peyton Jones2015-12-011-12/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch began as a modest refactoring of HsType and friends, to clarify and tidy up exactly where quantification takes place in types. Although initially driven by making the implementation of wildcards more tidy (and fixing a number of bugs), I gradually got drawn into a pretty big process, which I've been doing on and off for quite a long time. There is one compiler performance regression as a result of all this, in perf/compiler/T3064. I still need to look into that. * The principal driving change is described in Note [HsType binders] in HsType. Well worth reading! * Those data type changes drive almost everything else. In particular we now statically know where (a) implicit quantification only (LHsSigType), e.g. in instance declaratios and SPECIALISE signatures (b) implicit quantification and wildcards (LHsSigWcType) can appear, e.g. in function type signatures * As part of this change, HsForAllTy is (a) simplified (no wildcards) and (b) split into HsForAllTy and HsQualTy. The two contructors appear when and only when the correponding user-level construct appears. Again see Note [HsType binders]. HsExplicitFlag disappears altogether. * Other simplifications - ExprWithTySig no longer needs an ExprWithTySigOut variant - TypeSig no longer needs a PostRn name [name] field for wildcards - PatSynSig records a LHsSigType rather than the decomposed pieces - The mysterious 'GenericSig' is now 'ClassOpSig' * Renamed LHsTyVarBndrs to LHsQTyVars * There are some uninteresting knock-on changes in Haddock, because of the HsSyn changes I also did a bunch of loosely-related changes: * We already had type synonyms CoercionN/CoercionR for nominal and representational coercions. I've added similar treatment for TcCoercionN/TcCoercionR mkWpCastN/mkWpCastN All just type synonyms but jolly useful. * I record-ised ForeignImport and ForeignExport * I improved the (poor) fix to Trac #10896, by making TcTyClsDecls.checkValidTyCl recover from errors, but adding a harmless, abstract TyCon to the envt if so. * I did some significant refactoring in RnEnv.lookupSubBndrOcc, for reasons that I have (embarrassingly) now totally forgotten. It had to do with something to do with import and export Updates haddock submodule.
* Refactor default methods (Trac #11105)Simon Peyton Jones2015-11-255-29/+61
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch does some signficant refactoring to the treatment of default methods in class declarations, and more generally to the type checking of type/class decls. Highlights: * When the class has a generic-default method, such as class C a where op :: a -> a -> Bool default op :: Ord a => a -> a -> a the ClassOpItem records the type of the generic-default, in this case the type (Ord a => a -> a -> a) * I killed off Class.DefMeth in favour of the very-similar BasicTypes.DefMethSpec. However it turned out to be better to use a Maybe, thus Maybe (DefMethSpec Type) with Nothing meaning "no default method". * In TcTyClsDecls.tcTyClGroup, we used to accumulate a [TyThing], but I found a way to make it much simpler, accumulating only a [TyCon]. Much less wrapping and unwrapping. * On the way I also fixed Trac #10896 in a better way. Instead of killing off all ambiguity checks whenever there are any type errors (the fix in commit 8e8b9ed), I instead recover in TcTyClsDecls.checkValidTyCl. There was a lot of associated simplification all round
* Support multiple debug output levelsBen Gamari2015-11-231-2/+2
| | | | | | | | | We now only strip block information from DebugBlocks when compiling with `-g1`, intended to be used when only minimal debug information is desired. `-g2` is assumed when `-g` is passed without any integer argument. Differential Revision: https://phabricator.haskell.org/D1281
* Fix inconsistent pretty-printing of type familiesMichał Sośnicki2015-11-182-5/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | After the changes, the three functions used to print type families were identical, so they are refactored into one. Original RHSs of data instance declarations are recreated and printed in user error messages. RHSs containing representation TyCons are printed in the Coercion Axioms section in a typechecker dump. Add vbar to the list of SDocs exported by Outputable. Replace all text "|" docs with it. Fixes #10839 Reviewers: goldfire, jstolarek, austin, bgamari Reviewed By: jstolarek Subscribers: jstolarek, thomie Differential Revision: https://phabricator.haskell.org/D1441 GHC Trac Issues: #10839
* Revert "Unify hsig and hs-boot; add preliminary "hs-boot" merging."Edward Z. Yang2015-11-162-41/+8
| | | | | | | | | | | | | | | Summary: This reverts commit 06d46b1e4507e09eb2a7a04998a92610c8dc6277. This also has a Haddock submodule update. Test Plan: validate Reviewers: simonpj, austin, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1475
* Move usage calculation to desugaring, simplifying ModGuts.Edward Z. Yang2015-11-161-197/+15
| | | | | | | | | | | | | | | | Summary: (This patch was excised from the fat interfaces patch, which has been put indefinitely on hold.) Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu> Test Plan: validate Reviewers: simonpj, austin, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1469
* Turn ImportedModsVal into a data typeJoachim Breitner2015-11-131-3/+3
| | | | | it was a 4-tuple before my patch, and a 6-tuple afterwards. Clearly a record type is in order here!
* Give helpful advice when a fully qualified name is not in scopeJoachim Breitner2015-11-131-3/+3
| | | | | | | | | | This implements #11071. It needs to thread through a GlobalRdrEnv corresponding to the export list of the module if its exports were not restricted. A refactoring of ImportedModsVal into a proper data type follows. Differential Revision: https://phabricator.haskell.org/D1462
* Associate pattern synonyms with types in module exportsMatthew Pickering2015-11-112-2/+2
| | | | | | | | | | | | | | | | | | | | | | This patch implements #10653. It adds the ability to bundle pattern synonyms with type constructors in export lists so that users can treat pattern synonyms more like data constructors. Updates haddock submodule. Test Plan: ./validate Reviewers: goldfire, austin, bgamari Reviewed By: bgamari Subscribers: simonpj, gridaphobe, thomie Differential Revision: https://phabricator.haskell.org/D1258 GHC Trac Issues: #10653
* Generate Typeable info at definition sitesBen Gamari2015-10-304-112/+130
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is the second attempt at merging D757. This patch implements the idea floated in Trac #9858, namely that we should generate type-representation information at the data type declaration site, rather than when solving a Typeable constraint. However, this turned out quite a bit harder than I expected. I still think it's the right thing to do, and it's done now, but it was quite a struggle. See particularly * Note [Grand plan for Typeable] in TcTypeable (which is a new module) * Note [The overall promotion story] in DataCon (clarifies existing stuff) The most painful bit was that to generate Typeable instances (ie TyConRepName bindings) for every TyCon is tricky for types in ghc-prim etc: * We need to have enough data types around to *define* a TyCon * Many of these types are wired-in Also, to minimise the code generated for each data type, I wanted to generate pure data, not CAFs with unpackCString# stuff floating about. Performance ~~~~~~~~~~~ Three perf/compiler tests start to allocate quite a bit more. This isn't surprising, because they all allocate zillions of data types, with practically no other code, esp. T1969 * T1969: GHC allocates 19% more * T4801: GHC allocates 13% more * T5321FD: GHC allocates 13% more * T9675: GHC allocates 11% more * T783: GHC allocates 11% more * T5642: GHC allocates 10% more I'm treating this as acceptable. The payoff comes in Typeable-heavy code. Remaining to do ~~~~~~~~~~~~~~~ * I think that "TyCon" and "Module" are over-generic names to use for the runtime type representations used in GHC.Typeable. Better might be "TrTyCon" and "TrModule". But I have not yet done this * Add more info the the "TyCon" e.g. source location where it was defined * Use the new "Module" type to help with Trac Trac #10068 * It would be possible to generate TyConRepName (ie Typeable instances) selectively rather than all the time. We'd need to persist the information in interface files. Lacking a motivating reason I have not done this, but it would not be difficult. Refactoring ~~~~~~~~~~~ As is so often the case, I ended up refactoring more than I intended. In particular * In TyCon, a type *family* (whether type or data) is repesented by a FamilyTyCon * a algebraic data type (including data/newtype instances) is represented by AlgTyCon This wasn't true before; a data family was represented as an AlgTyCon. There are some corresponding changes in IfaceSyn. * Also get rid of the (unhelpfully named) tyConParent. * In TyCon define 'Promoted', isomorphic to Maybe, used when things are optionally promoted; and use it elsewhere in GHC. * Cleanup handling of knownKeyNames * Each TyCon, including promoted TyCons, contains its TyConRepName, if it has one. This is, in effect, the name of its Typeable instance. Updates haddock submodule Test Plan: Let Harbormaster validate Reviewers: austin, hvr, goldfire Subscribers: goldfire, thomie Differential Revision: https://phabricator.haskell.org/D1404 GHC Trac Issues: #9858
* Revert "Generate Typeable info at definition sites"Ben Gamari2015-10-294-130/+112
| | | | | | | | This reverts commit bef2f03e4d56d88a7e9752a7afd6a0a35616da6c. This merge was botched Also reverts haddock submodule.
* Generate Typeable info at definition sitesBen Gamari2015-10-294-112/+130
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch implements the idea floated in Trac #9858, namely that we should generate type-representation information at the data type declaration site, rather than when solving a Typeable constraint. However, this turned out quite a bit harder than I expected. I still think it's the right thing to do, and it's done now, but it was quite a struggle. See particularly * Note [Grand plan for Typeable] in TcTypeable (which is a new module) * Note [The overall promotion story] in DataCon (clarifies existing stuff) The most painful bit was that to generate Typeable instances (ie TyConRepName bindings) for every TyCon is tricky for types in ghc-prim etc: * We need to have enough data types around to *define* a TyCon * Many of these types are wired-in Also, to minimise the code generated for each data type, I wanted to generate pure data, not CAFs with unpackCString# stuff floating about. Performance ~~~~~~~~~~~ Three perf/compiler tests start to allocate quite a bit more. This isn't surprising, because they all allocate zillions of data types, with practically no other code, esp. T1969 * T3294: GHC allocates 110% more (filed #11030 to track this) * T1969: GHC allocates 30% more * T4801: GHC allocates 14% more * T5321FD: GHC allocates 13% more * T783: GHC allocates 12% more * T9675: GHC allocates 12% more * T5642: GHC allocates 10% more * T9961: GHC allocates 6% more * T9203: Program allocates 54% less I'm treating this as acceptable. The payoff comes in Typeable-heavy code. Remaining to do ~~~~~~~~~~~~~~~ * I think that "TyCon" and "Module" are over-generic names to use for the runtime type representations used in GHC.Typeable. Better might be "TrTyCon" and "TrModule". But I have not yet done this * Add more info the the "TyCon" e.g. source location where it was defined * Use the new "Module" type to help with Trac Trac #10068 * It would be possible to generate TyConRepName (ie Typeable instances) selectively rather than all the time. We'd need to persist the information in interface files. Lacking a motivating reason I have not done this, but it would not be difficult. Refactoring ~~~~~~~~~~~ As is so often the case, I ended up refactoring more than I intended. In particular * In TyCon, a type *family* (whether type or data) is repesented by a FamilyTyCon * a algebraic data type (including data/newtype instances) is represented by AlgTyCon This wasn't true before; a data family was represented as an AlgTyCon. There are some corresponding changes in IfaceSyn. * Also get rid of the (unhelpfully named) tyConParent. * In TyCon define 'Promoted', isomorphic to Maybe, used when things are optionally promoted; and use it elsewhere in GHC. * Cleanup handling of knownKeyNames * Each TyCon, including promoted TyCons, contains its TyConRepName, if it has one. This is, in effect, the name of its Typeable instance. Requires update of the haddock submodule. Differential Revision: https://phabricator.haskell.org/D757
* Record pattern synonymsMatthew Pickering2015-10-294-14/+33
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch implements an extension to pattern synonyms which allows user to specify pattern synonyms using record syntax. Doing so generates appropriate selectors and update functions. === Interaction with Duplicate Record Fields === The implementation given here isn't quite as general as it could be with respect to the recently-introduced `DuplicateRecordFields` extension. Consider the following module: {-# LANGUAGE DuplicateRecordFields #-} {-# LANGUAGE PatternSynonyms #-} module Main where pattern S{a, b} = (a, b) pattern T{a} = Just a main = do print S{ a = "fst", b = "snd" } print T{ a = "a" } In principle, this ought to work, because there is no ambiguity. But at the moment it leads to a "multiple declarations of a" error. The problem is that pattern synonym record selectors don't do the same name mangling as normal datatypes when DuplicateRecordFields is enabled. They could, but this would require some work to track the field label and selector name separately. In particular, we currently represent datatype selectors in the third component of AvailTC, but pattern synonym selectors are just represented as Avails (because they don't have a corresponding type constructor). Moreover, the GlobalRdrElt for a selector currently requires it to have a parent tycon. (example due to Adam Gundry) === Updating Explicitly Bidirectional Pattern Synonyms === Consider the following ``` pattern Silly{a} <- [a] where Silly a = [a, a] f1 = a [5] -- 5 f2 = [5] {a = 6} -- currently [6,6] ``` === Fixing Polymorphic Updates === They were fixed by adding these two lines in `dsExpr`. This might break record updates but will be easy to fix. ``` + ; let req_wrap = mkWpTyApps (mkTyVarTys univ_tvs) - , pat_wrap = idHsWrapper } +, pat_wrap = req_wrap } ``` === Mixed selectors error === Note [Mixed Record Field Updates] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Consider the following pattern synonym. data MyRec = MyRec { foo :: Int, qux :: String } pattern HisRec{f1, f2} = MyRec{foo = f1, qux=f2} This allows updates such as the following updater :: MyRec -> MyRec updater a = a {f1 = 1 } It would also make sense to allow the following update (which we reject). updater a = a {f1 = 1, qux = "two" } ==? MyRec 1 "two" This leads to confusing behaviour when the selectors in fact refer the same field. updater a = a {f1 = 1, foo = 2} ==? ??? For this reason, we reject a mixture of pattern synonym and normal record selectors in the same update block. Although of course we still allow the following. updater a = (a {f1 = 1}) {foo = 2} > updater (MyRec 0 "str") MyRec 2 "str"
* Pattern synonyms: swap provided/requiredSimon Peyton Jones2015-10-282-2/+2
| | | | | | | | | | | | | | This patch swaps the order of provided and required constraints in a pattern signature, so it now goes pattern P :: req => prov => t1 -> ... tn -> res_ty See the long discussion in Trac #10928. I think I have found all the places, but I could have missed something particularly in comments. There is a Haddock changes; so a submodule update.
* Sort field labels before fingerprint hashingBartosz Nitka2015-10-271-1/+8
| | | | | | | | | | | | | | | | | | `fsEnvElts :: FastStringEnv a -> [a]` returns a list of `[a]` in the order of `Unique`s which is arbitrary. In this case it gives a list of record fields in arbitrary order, from which we then extract the field labels to contribute to the record fingerprint. The arbitrary ordering of field labels introduces unnecessary nondeterminism in interface files as demonstrated by the test case. We sort `FastString` here. It's safe, because the only way that the `Unique` associated with the `FastString` is used in comparison is for equality. If the `Unique`s are different it fallbacks to comparing the actual `ByteString`. Reviewed By: ezyang, thomie, bgamari, austin Differential Revision: https://phabricator.haskell.org/D1373 GHC Trac Issues: #4012
* Implement DuplicateRecordFieldsAdam Gundry2015-10-165-52/+94
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This implements DuplicateRecordFields, the first part of the OverloadedRecordFields extension, as described at https://ghc.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields/DuplicateRecordFields This includes fairly wide-ranging changes in order to allow multiple records within the same module to use the same field names. Note that it does *not* allow record selector functions to be used if they are ambiguous, and it does not have any form of type-based disambiguation for selectors (but it does for updates). Subsequent parts will make overloading selectors possible using orthogonal extensions, as described on the wiki pages. This part touches quite a lot of the codebase, and requires changes to several GHC API datatypes in order to distinguish between field labels (which may be overloaded) and selector function names (which are always unique). The Haddock submodule has been adapted to compile with the GHC API changes, but it will need further work to properly support modules that use the DuplicateRecordFields extension. Test Plan: New tests added in testsuite/tests/overloadedrecflds; these will be extended once the other parts are implemented. Reviewers: goldfire, bgamari, simonpj, austin Subscribers: sjcjoosten, haggholm, mpickering, bgamari, tibbe, thomie, goldfire Differential Revision: https://phabricator.haskell.org/D761
* Rename package key to unit ID, and installed package ID to component ID.Edward Z. Yang2015-10-143-12/+12
| | | | | | Comes with Haddock submodule update. Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
* Simplify type of ms_srcimps and ms_textual_imps.Edward Z. Yang2015-10-091-2/+2
| | | | | | | | | | | | | | | | | Summary: Previously, we stored an entire ImportDecl, which was pretty wasteful since all we really cared about was the package qualifier and the module name. Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu> Test Plan: validate Reviewers: bgamari, austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1317
* Move orphan instance/rule warnings to typechecker/desugarer.Edward Z. Yang2015-10-081-78/+15
| | | | | | | | | | | | | | | | | | | | | | Summary: Instead of doing these warnings at MkIface time, we do them when we create the instances/rules in the typechecker/desugarer. Emitting warnings for auto-generated instances was a pain (since the specialization monad doesn't have the capacity to emit warnings) so instead I just deprecated -fwarn-auto-orphans. Auto rule orphans are pretty harmless anyway: they don't cause interface files to be eagerly loaded in. Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu> Test Plan: validate Reviewers: simonpj, austin, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1297
* Unify hsig and hs-boot; add preliminary "hs-boot" merging.Edward Z. Yang2015-09-212-8/+41
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch drops the file level distinction between hs-boot and hsig; we figure out which one we are compiling based on whether or not there is a corresponding hs file lying around. To make the "import A" syntax continue to work for bare hs-boot files, we also introduce hs-boot merging, which takes an A.hi-boot and converts it to an A.hi when there is no A.hs file in scope. This will be generalized in Backpack to merge multiple A.hi files together; which means we can jettison the "load multiple interface files" functionality. This works automatically for --make, but for one-shot compilation we need a new mode: ghc --merge-requirements A will generate an A.hi/A.o from a local A.hi-boot file; Backpack will extend this mechanism further. Has Haddock submodule update to deal with change in msHsFilePath behavior. - This commit drops support for the hsig extension. Can we support it? It's annoying because the finder code is written with the assumption that where there's an hs-boot file, there's always an hs file too. To support hsig, you'd have to probe two locations. Easier to just not support it. - #10333 affects us, modifying an hs-boot still doesn't trigger recomp. - See compiler/main/Finder.hs: this diff is very skeevy, but it seems to work. - This code cunningly doesn't drop hs-boot files from the "drop hs-boot files" module graph, if they don't have a corresponding hs file. I have no idea if this actually is useful. Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu> Test Plan: validate Reviewers: simonpj, austin, bgamari, spinda Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1098
* Revert "Revert "Revert "Change loadSrcInterface to return a list of ModIface"""Edward Z. Yang2015-09-211-44/+6
| | | | This reverts commit 0c6c015d42c2bd0ee008f790c7c0cb4c5b78ca6b.
* Revert "Revert "Revert "Support for multiple signature files in scope."""Edward Z. Yang2015-09-212-26/+10
| | | | This reverts commit 214596de224afa576a9c295bcf53c6941d6892e0.
* Refactor BranchLists.Richard Eisenberg2015-09-212-6/+7
| | | | | | | | Now we use Array to store branches. This makes sense because we often have to do random access (once inference is done). This also vastly simplifies the awkward BranchList type. This fixes #10837 and updates submodule utils/haddock.
* Perform a validity check on assoc type defaults.Richard Eisenberg2015-09-212-2/+2
| | | | | | | | | This fixes #10817 and #10899. A knock-on effect is that we must now remember locations of associated type defaults for error messages during validity checking. This isn't too bad, but it increases the size of the diff somewhat. Test cases: indexed-types/should_fail/T108{17,99}
* Show minimal complete definitions in ghci (#10847)Moritz Kiefer2015-09-171-3/+27
| | | | | | | | | | | Show the minimal complete definition on :info in ghci. They are shown like MINIMAL pragmas in code. If the minimal complete definition is empty or only a specific method from a class is requested, nothing is shown. Reviewed By: simonpj, austin, thomie Differential Revision: https://phabricator.haskell.org/D1241
View Lorry Controller Status