summaryrefslogtreecommitdiff
path: root/testsuite/tests/polykinds
Commit message (Collapse)AuthorAgeFilesLines
* Address #11471 by putting RuntimeRep in kinds.wip/runtime-repRichard Eisenberg2016-02-243-4/+4
| | | | | | | | | | | | | | | | | | | | | 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.
* Testsuite: delete Windows line endings [skip ci] (#11631)Thomas Miedema2016-02-231-5/+5
|
* Testsuite: accept output without Windows line endings (#11631)Thomas Miedema2016-02-232-13/+14
|
* Testsuite: delete Windows line endings [skip ci] (#11631)Thomas Miedema2016-02-239-127/+127
|
* Add a testcase for #11362Bartosz Nitka2016-02-152-0/+28
| | | | | | | | | | | | | | | | This reproduces the issue that I encountered in #11362. Test Plan: this testcase Reviewers: simonpj, bgamari, austin Reviewed By: simonpj Subscribers: thomie, simonmar Differential Revision: https://phabricator.haskell.org/D1917 GHC Trac Issues: #11362
* A tiny, outright bug in tcDataFamInstDeclSimon Peyton Jones2016-02-151-2/+19
| | | | | | | | | | | | | | This bug was revealed by Trac #11362. It turns out that in my patch for Trac #11148 (namely 1160dc5), I failed to turn one occurrence of tvs' into full_tvs. Sigh. This is tricky stuff and it cost me several hours to page it back in and figure out what was happening. The result was a CoAxiom whose lhs had rhs had different kinds. Eeek! Anyway it's fixed. I also added an ASSERT, in FamInst.newFamInst, that trips on such bogus CoAxioms.
* Wrap solveEqualities in checkNoErrsSimon Peyton Jones2016-02-107-0/+57
| | | | | | | | | This simple change fixes Trac #11563, #11520, #11516, #11399. See esp the comments in #11520. See Note [Fail fast on kind errors] in TcSimplify Merge to 8.0 branch
* Fix a nasty superclass expansion bugSimon Peyton Jones2016-02-082-0/+90
| | | | | | | | | | | | | | | | This patch fixes Trac #11523. * The basic problem was that TcRnTypes.superClassesMightHelp was returning True of a Derived constraint, and that led to us expanding Given superclasses, which produced the same Derived constraint again, and so on infinitely. We really want to do this only if there are unsolve /Wanted/ contraints! * On the way I made TcSMonad.getUnsolvedInerts a bit more discriminating about which Derived equalities it returns; see Note [Unsolved Derived equalities] in TcSMonad * Lots of new comments in TcSMonad.
* Add Edward Kmett's example as a test caseSimon Peyton Jones2016-02-082-0/+197
| | | | This is a more stressful example of T11480.
* Refactor the typechecker to use ExpTypes.Richard Eisenberg2016-01-271-8/+8
| | | | | | | | | | | | | | | | | | | | | The idea here is described in [wiki:Typechecker]. Briefly, this refactor keeps solid track of "synthesis" mode vs "checking" in GHC's bidirectional type-checking algorithm. When in synthesis mode, the expected type is just an IORef to write to. In addition, this patch does a significant reworking of RebindableSyntax, allowing much more freedom in the types of the rebindable operators. For example, we can now have `negate :: Int -> Bool` and `(>>=) :: m a -> (forall x. a x -> m b) -> m b`. The magic is in tcSyntaxOp. This addresses tickets #11397, #11452, and #11458. Tests: typecheck/should_compile/{RebindHR,RebindNegate,T11397,T11458} th/T11452
* Fix exprIsHNF (Trac #11248)Simon Peyton Jones2016-01-251-0/+3
| | | | | | | | | | | | | | | Blimey! CoreUtils.exprIsHNFlike had not one but two bugs. * is_hnf_like treated coercion args like type args (result: exprIsHNF might wrongly say True) * app_is_value treated type args like value args (result: exprIsHNF might wrongly say False) Bizarre. This goes back to at least 2012. It's amazing that it hasn't caused more trouble. It was discovered by a Lint error when compiling Trac #11248 with -O.
* Avoid recursive use of immSuperClassesSimon Peyton Jones2016-01-251-1/+1
| | | | | | | | In fixing Trac #11480 I had omitted to deal with FunDeps.oclose, which was making recursive use of immSuperClasses, and hence going into a loop in the recursive case. Solution: use transSuperClasses, which takes care not to.
* Special-case implicit params in superclass expansionSimon Peyton Jones2016-01-252-0/+27
| | | | | | | | | | | | | | | This issue came up in Trac #11480, and is documented in Note [When superclasses help] in TcRnTypes. We were getting a spurious warning T11480.hs:1:1: warning: solveWanteds: too many iterations (limit = 4) The fix is easy. A bit of refactoring along the way. The original bug report in Trac #11480 appears to work fine in HEAD and the 8.0 branch but I added a regression test in this commit as well.
* Add expected stderr for #11466 test caseJoachim Breitner2016-01-221-0/+6
|
* Allow implicit parameters in constraint synonymsSimon Peyton Jones2016-01-212-1/+18
| | | | | | | | This fixes Trac #11466. It went bad by accident in commit ffc21506894c7887d3620423aaf86bc6113a1071 Refactor tuple constraints
* Re-add missing kind generalisationSimon Peyton Jones2016-01-213-0/+24
| | | | | | | | | | | | When splitting H98/GADT syntax in ConDecl we lost a key kind-generalisation step. I also renamed tcHsTyVarBndrs to tcExplicitTKBnders, by analogy with tcImplicitTkBndrs. This fixes Trac #11459. Merge to 8.0.
* Fix #11255.Richard Eisenberg2015-12-262-0/+7
| | | | We need to instantiate types in tuples. Quite straightforward.
* Visible type applicationRichard Eisenberg2015-12-248-14/+37
| | | | | | | | | | | | | 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.
* Fix super-class cycle checkSimon Peyton Jones2015-12-232-1/+7
| | | | Fixes Trac #11278
* Test Trac #11248, #11249Simon Peyton Jones2015-12-183-0/+86
|
* Fix tcTyClTyVars to handle SigTvsRichard Eisenberg2015-12-171-1/+1
| | | | | | | | | | | | | | Previously, tcTyClTyVars required that the names of the LHsQTyVars matched up exactly with the names of the kind of the given TyCon. It now does a bit of matching up when necessary to relax this restriction. This commit enables a few tests that had previously been disabled. The shortcoming this addresses is discussed in #11203, but that ticket is not directly addressed here. Test case: polykinds/SigTvKinds, perf/compiler/T9872d
* Allow recursive (undecidable) superclassesSimon Peyton Jones2015-12-154-32/+40
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch fulfils the request in Trac #11067, #10318, and #10592, by lifting the conservative restrictions on superclass constraints. These restrictions are there (and have been since Haskell was born) to ensure that the transitive superclasses of a class constraint is a finite set. However (a) this restriction is conservative, and can be annoying when there really is no recursion, and (b) sometimes genuinely recursive superclasses are useful (see the tickets). Dimitrios and I worked out that there is actually a relatively simple way to do the job. It’s described in some detail in Note [The superclass story] in TcCanonical Note [Expanding superclasses] in TcType In brief, the idea is to expand superclasses only finitely, but to iterate (using a loop that already existed) if there are more superclasses to explore. Other small things - I improved grouping of error messages a bit in TcErrors - I re-centred the haddock.compiler test, which was at 9.8% above the norm, and which this patch pushed slightly over
* Test #9017 in polykinds/T9017Richard Eisenberg2015-12-113-0/+35
|
* Add kind equalities to GHC.Richard Eisenberg2015-12-1137-156/+217
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Refactor treatment of wildcardsSimon Peyton Jones2015-12-0111-82/+80
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Rearrange error msgs and add section markers (Trac #11014).Evan Laforge2015-11-243-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This puts the "Relevant bindings" section at the end. It uses a TcErrors.Report Monoid to divide messages by importance and then mappends them together. This is not the most efficient way since there are various intermediate Reports and list appends, but it probably doesn't matter since error messages shouldn't get that large, and are usually prepended. In practice, everything is `important` except `relevantBindings`, which is `supplementary`. ErrMsg's errMsgShortDoc and errMsgExtraInfo were extracted into ErrDoc, which has important, context, and suppelementary fields. Each of those three sections is marked with a bullet character, '•' on unicode terminals and '*' on ascii terminals. Since this breaks tons of tests, I also modified testlib.normalise_errmsg to strip out '•'s. --- Additional notes: To avoid prepending * to an empty doc, I needed to filter empty docs. This seemed less error-prone than trying to modify everyone who produces SDoc to instead produce Maybe SDoc. So I added `Outputable.isEmpty`. Unfortunately it needs a DynFlags, which is kind of bogus, but otherwise I think I'd need another Empty case for SDoc, and then it couldn't be a newtype any more. ErrMsg's errMsgShortString is only used by the Show instance, which is in turn only used by Show HscTypes.SourceError, which is in turn only needed for the Exception instance. So it's probably possible to get rid of errMsgShortString, but that would a be an unrelated cleanup. Fixes #11014. Test Plan: see above Reviewers: austin, simonpj, thomie, bgamari Reviewed By: thomie, bgamari Subscribers: simonpj, nomeata, thomie Differential Revision: https://phabricator.haskell.org/D1427 GHC Trac Issues: #11014
* Create a deterministic version of tyVarsOfTypeBartosz Nitka2015-11-211-24/+24
| | | | | | | | | | | | | | | | | | | | | | | | I've run into situations where I need deterministic `tyVarsOfType` and this implementation achieves that and also brings an algorithmic improvement. Union of two `VarSet`s takes linear time the size of the sets and in the worst case we can have `n` unions of sets of sizes `(n-1, 1), (n-2, 1)...` making it quadratic. One reason why we need deterministic `tyVarsOfType` is in `abstractVars` in `SetLevels`. When we abstract type variables when floating we want them to be abstracted in deterministic order. Test Plan: harbormaster Reviewers: simonpj, goldfire, austin, hvr, simonmar, bgamari Reviewed By: simonmar Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1468 GHC Trac Issues: #4012
* Fix inconsistent pretty-printing of type familiesMichał Sośnicki2015-11-181-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Generate Typeable info at definition sitesBen Gamari2015-10-301-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-291-2/+2
| | | | | | | | This reverts commit bef2f03e4d56d88a7e9752a7afd6a0a35616da6c. This merge was botched Also reverts haddock submodule.
* Generate Typeable info at definition sitesBen Gamari2015-10-291-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Fix kind-var abstraction in SimplUtils.abstractFloatsSimon Peyton Jones2015-10-062-0/+39
| | | | | | | A missing 'closeOverKinds' triggered Trac #10934. Happily the fix is simple. Merge to 7.10.3
* Test Trac #10742Simon Peyton Jones2015-08-062-0/+15
|
* Test Trac #10134Simon Peyton Jones2015-08-033-0/+31
|
* Fix Trac #10670Simon Peyton Jones2015-07-233-0/+80
| | | | | | In dataConCannotMatch we were using a GADT data con without properly instantiating the existential type variables. The fix is easy, and the code is tighter.
* Testsuite: delete remaining only_compiler_types(['ghc']) setupsThomas Miedema2015-07-141-2/+0
| | | | | No point in pretending other compilers can use the GHC testsuite. This makes the *.T files a bit shorter.
* Improve error message for fundepsSimon Peyton Jones2015-07-104-1/+23
| | | | | | | Improve error message fundeps, especially when PolyKinds means that the un-determined variables are (invisible) kind variables. See Trac #10570.
* Test Trac #10503Simon Peyton Jones2015-06-183-0/+26
|
* Remove some horrible munging of origins for CoercibleSimon Peyton Jones2015-06-181-5/+5
| | | | | | | | | | | | | | | | | | | | I just didn't think it was buying enough for all the cruft it caused. We can put some back if people start complaining about poor error messages. I forget quite how I tripped over this but I got sucked in. * Lots of tidying up in TcErrors * Rename pprArisingAt to pprCtLoc, by analogy with pprCtOrigin * Remove CoercibleOrigin data constructor from CtOrigin * Make relevantBindings return a Ct with a zonked and tidied CtOrigin * Add to TcRnTypes ctOrigin :: Ct -> CtOrigin ctEvOrigin :: CtEvidence -> CtOrigin setCtLoc :: Ct -> CtLoc -> Ct
* Report arity errors correctly despite kindsSimon Peyton Jones2015-06-184-24/+38
| | | | | | | | | | | | Trac #10516 pointed out that when reporting arity errors (like "T needs 2 arguments but has been given 1"), we should not count kind arguments, since they are implicit. If we include kind args in the count, we get very confusing error messages indeed. I did a little bit of refactoring which make some error messages wobble around. But the payload of this fix is in TcValidity.tyConArityErr
* Increase constraint tuple limit to 62 (Trac #10451)Nick Terrell2015-06-142-3/+35
| | | | | | | | | | | * Increase max constraint tuple size to 62 * Modify test case to reflect change Reviewed By: austin Differential Revision: https://phabricator.haskell.org/D986 GHC Trac Issues: #10451
* Test Trac #10451Simon Peyton Jones2015-06-023-1/+18
|
* Custom `Typeable` solver, that keeps track of kinds.Iavor S. Diatchki2015-03-071-3/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This implements the new `Typeable` solver: when GHC sees `Typeable` constraints it solves them on the spot. The current implementation creates `TyCon` representations on the spot. Pro: No overhead at all in code that does not use `Typeable` Cons: Code that uses `Typeable` may create multipe `TyCon` represntations. We have discussed an implementation where representations of `TyCons` are computed once, in the module, where a datatype is declared. This would lead to more code being generated: for a promotable datatype we need to generate `2 + number_of_data_cons` type-constructro representations, and we have to do that for all programs, even ones that do not intend to use typeable. I added code to emit warning whenevar `deriving Typeable` is encountered--- the idea being that this is not needed anymore, and shold be fixed. Also, we allow `instance Typeable T` in .hs-boot files, but they result in a warning, and are ignored. This last one was to avoid breaking exisitng code, and should become an error, eventually. Test Plan: 1. GHC can compile itself. 2. I compiled a number of large libraries, including `lens`. - I had to make some small changes: `unordered-containers` uses internals of `TypeReps`, so I had to do a 1 line fix - `lens` needed one instance changed, due to a poly-kinded `Typeble` instance 3. I also run some code that uses `syb` to traverse a largish datastrucutre. I didn't notice any signifiant performance difference between the 7.8.3 version, and this implementation. Reviewers: simonpj, simonmar, austin, hvr Reviewed By: austin, hvr Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D652 GHC Trac Issues: #9858
* A raft of small changes associated with -XConstrainedClassMethodsSimon Peyton Jones2015-03-043-20/+22
| | | | | | | | | | | | | | | | | | | | | | | | | See Trac #7854. Specifically: * Major clean up and simplification of check_op in checkValidClass; specifically - use checkValidType on the entire method-selector type to detect ambiguity - put a specific test for -XConstrainedClassMethods * Make -XConstrainedClassMethods be implied by -XMultiParamTypeClasses (a bit ad-hoc but see #7854), and document in the user manual. * Do the checkAmbiguity test just once in TcValidity.checkValidType, rather than repeatedly at every level. See Note [When to call checkAmbiguity] * Add -XAllowAmbiguousTypes in GHC.IP, since 'ip' really is ambiguous. (It's a rather magic function.) * Improve location info for check_op in checkValidClass * Update quite a few tests, which had genuinely-ambiguous class method signatures. Some I fixed by making them unambiguous; some by adding -XAllowAmbiguousTypes
* Test Trac #10041Simon Peyton Jones2015-02-062-0/+12
|
* Major patch to add -fwarn-redundant-constraintsSimon Peyton Jones2015-01-069-2/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The idea was promted by Trac #9939, but it was Christmas, so I did some recreational programming that went much further. The idea is to warn when a constraint in a user-supplied context is redundant. Everything is described in detail in Note [Tracking redundant constraints] in TcSimplify. Main changes: * The new ic_status field in an implication, of type ImplicStatus. It replaces ic_insol, and includes information about redundant constraints. * New function TcSimplify.setImplicationStatus sets the ic_status. * TcSigInfo has sig_report_redundant field to say whenther a redundant constraint should be reported; and similarly the FunSigCtxt constructor of UserTypeCtxt * EvBinds has a field eb_is_given, to record whether it is a given or wanted binding. Some consequential chagnes to creating an evidence binding (so that we record whether it is given or wanted). * AbsBinds field abs_ev_binds is now a *list* of TcEvBiinds; see Note [Typechecking plan for instance declarations] in TcInstDcls * Some significant changes to the type checking of instance declarations; Note [Typechecking plan for instance declarations] in TcInstDcls. * I found that TcErrors.relevantBindings was failing to zonk the origin of the constraint it was looking at, and hence failing to find some relevant bindings. Easy to fix, and orthogonal to everything else, but hard to disentangle. Some minor refactorig: * TcMType.newSimpleWanteds moves to Inst, renamed as newWanteds * TcClassDcl and TcInstDcls now have their own code for typechecking a method body, rather than sharing a single function. The shared function (ws TcClassDcl.tcInstanceMethodBody) didn't have much code and the differences were growing confusing. * Add new function TcRnMonad.pushLevelAndCaptureConstraints, and use it * Add new function Bag.catBagMaybes, and use it in TcSimplify
* Print singleton consraints without parensSimon Peyton Jones2015-01-065-68/+68
| | | | | | | | | | The main change is in TypeRep.pprTheta, so we print Eq a for a singleton, but (Eq a, Show a) for multiple constraints. There are lots of trivial knock-on changes to error messages
* Modify a couple of error messages slightlySimon Peyton Jones2015-01-063-66/+66
| | | | | | | | | | | | In particular In the type signature for: f :: Int -> Int I added the colon Also reword the "maybe you haven't applied a function to enough arguments?" suggestion to make grammatical sense. These tiny changes affect a lot of error messages.
* Uncomment the instance signatures, to activate the testSimon Peyton Jones2014-12-021-3/+3
|
* Test Trac #7908Simon Peyton Jones2014-12-012-1/+50
| | | | | Fixed by e6a2050ebb6da316aecec66a6795715fbab355ca along with #9582, #9833
View Lorry Controller Status