summaryrefslogtreecommitdiff
path: root/testsuite/tests/indexed-types/should_fail/all.T
Commit message (Collapse)AuthorAgeFilesLines
* Remove flattening variablesRichard Eisenberg2020-12-011-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch redesigns the flattener to simplify type family applications directly instead of using flattening meta-variables and skolems. The key new innovation is the CanEqLHS type and the new CEqCan constraint (Ct). A CanEqLHS is either a type variable or exactly-saturated type family application; either can now be rewritten using a CEqCan constraint in the inert set. Because the flattener no longer reduces all type family applications to variables, there was some performance degradation if a lengthy type family application is now flattened over and over (not making progress). To compensate, this patch contains some extra optimizations in the flattener, leading to a number of performance improvements. Close #18875. Close #18910. There are many extra parts of the compiler that had to be affected in writing this patch: * The family-application cache (formerly the flat-cache) sometimes stores coercions built from Given inerts. When these inerts get kicked out, we must kick out from the cache as well. (This was, I believe, true previously, but somehow never caused trouble.) Kicking out from the cache requires adding a filterTM function to TrieMap. * This patch obviates the need to distinguish "blocking" coercion holes from non-blocking ones (which, previously, arose from CFunEqCans). There is thus some simplification around coercion holes. * Extra commentary throughout parts of the code I read through, to preserve the knowledge I gained while working. * A change in the pure unifier around unifying skolems with other types. Unifying a skolem now leads to SurelyApart, not MaybeApart, as documented in Note [Binding when looking up instances] in GHC.Core.InstEnv. * Some more use of MCoercion where appropriate. * Previously, class-instance lookup automatically noticed that e.g. C Int was a "unifier" to a target [W] C (F Bool), because the F Bool was flattened to a variable. Now, a little more care must be taken around checking for unifying instances. * Previously, tcSplitTyConApp_maybe would split (Eq a => a). This is silly, because (=>) is not a tycon in Haskell. Fixed now, but there are some knock-on changes in e.g. TrieMap code and in the canonicaliser. * New function anyFreeVarsOf{Type,Co} to check whether a free variable satisfies a certain predicate. * Type synonyms now remember whether or not they are "forgetful"; a forgetful synonym drops at least one argument. This is useful when flattening; see flattenView. * The pattern-match completeness checker invokes the solver. This invocation might need to look through newtypes when checking representational equality. Thus, the desugarer needs to keep track of the in-scope variables to know what newtype constructors are in scope. I bet this bug was around before but never noticed. * Extra-constraints wildcards are no longer simplified before printing. See Note [Do not simplify ConstraintHoles] in GHC.Tc.Solver. * Whether or not there are Given equalities has become slightly subtler. See the new HasGivenEqs datatype. * Note [Type variable cycles in Givens] in GHC.Tc.Solver.Canonical explains a significant new wrinkle in the new approach. * See Note [What might match later?] in GHC.Tc.Solver.Interact, which explains the fix to #18910. * The inert_count field of InertCans wasn't actually used, so I removed it. Though I (Richard) did the implementation, Simon PJ was very involved in design and review. This updates the Haddock submodule to avoid #18932 by adding a type signature. ------------------------- Metric Decrease: T12227 T5030 T9872a T9872b T9872c Metric Increase: T9872d -------------------------
* Postpone associated tyfam default checks until after typecheckingRyan Scott2020-09-091-0/+1
| | | | | | | | | | | | Previously, associated type family defaults were validity-checked during typechecking. Unfortunately, the error messages that these checks produce run the risk of printing knot-tied type constructors, which will cause GHC to diverge. In order to preserve the current error message's descriptiveness, this patch postpones these validity checks until after typechecking, which are now located in the new function `GHC.Tc.Validity.checkValidAssocTyFamDeflt`. Fixes #18648.
* Fix #13571 by adding an extension flag checkRichard Eisenberg2019-09-171-0/+2
| | | | Test case: indexed-types/should_fail/T13571
* Use injectiveVarsOfType to catch dodgy type family instance binders (#17008)Ryan Scott2019-08-021-0/+1
| | | | | | | | | | | | | | | | Previously, we detected dodgy type family instances binders by expanding type synonyms (via `exactTyCoVarsOfType`) and looking for type variables on the RHS that weren't mentioned on the (expanded) LHS. But this doesn't account for type families (like the example in #17008), so we instead use `injectiveVarsOfType` to only count LHS type variables that are in injective positions. That way, the `a` in `type instance F (x :: T a) = a` will not count if `T` is a type synonym _or_ a type family. Along the way, I moved `exactTyCoVarsOfType` to `TyCoFVs` to live alongside its sibling functions that also compute free variables. Fixes #17008.
* Use HsTyPats in associated type family defaultsRyan Scott2019-05-221-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Associated type family default declarations behave strangely in a couple of ways: 1. If one tries to bind the type variables with an explicit `forall`, the `forall`'d part will simply be ignored. (#16110) 2. One cannot use visible kind application syntax on the left-hand sides of associated default equations, unlike every other form of type family equation. (#16356) Both of these issues have a common solution. Instead of using `LHsQTyVars` to represent the left-hand side arguments of an associated default equation, we instead use `HsTyPats`, which is what other forms of type family equations use. In particular, here are some highlights of this patch: * `FamEqn` is no longer parameterized by a `pats` type variable, as the `feqn_pats` field is now always `HsTyPats`. * The new design for `FamEqn` in chronicled in `Note [Type family instance declarations in HsSyn]`. * `TyFamDefltEqn` now becomes the same thing as `TyFamInstEqn`. This means that many of `TyFamDefltEqn`'s code paths can now reuse the code paths for `TyFamInstEqn`, resulting in substantial simplifications to various parts of the code dealing with associated type family defaults. Fixes #16110 and #16356.
* Check for duplicate variables in associated default equationsRyan Scott2019-05-071-0/+1
| | | | | | | | | | | | | | | | A follow-up to !696's, which attempted to clean up the error messages for ill formed associated type family default equations. The previous attempt, !696, forgot to account for the possibility of duplicate kind variable arguments, as in the following example: ```hs class C (a :: j) where type T (a :: j) (b :: k) type T (a :: k) (b :: k) = k ``` This patch addresses this shortcoming by adding an additional check for this. Fixes #13971 (hopefully for good this time).
* Tweak error messages for narrowly-kinded assoc default declsRyan Scott2019-04-041-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This program, from #13971, currently has a rather confusing error message: ```hs class C a where type T a :: k type T a = Int ``` ``` • Kind mis-match on LHS of default declaration for ‘T’ • In the default type instance declaration for ‘T’ In the class declaration for ‘C’ ``` It's not at all obvious why GHC is complaining about the LHS until you realize that the default, when printed with `-fprint-explicit-kinds`, is actually `type T @{k} @* a = Int`. That is to say, the kind of `a` is being instantiated to `Type`, whereas it ought to be a kind variable. The primary thrust of this patch is to weak the error message to make this connection more obvious: ``` • Illegal argument ‘*’ in: ‘type T @{k} @* a = Int’ The arguments to ‘T’ must all be type variables • In the default type instance declaration for ‘T’ In the class declaration for ‘C’ ``` Along the way, I performed some code cleanup suggested by @rae in https://gitlab.haskell.org/ghc/ghc/issues/13971#note_191287. Before, we were creating a substitution from the default declaration's type variables to the type family tycon's type variables by way of `tcMatchTys`. But this is overkill, since we already know (from the aforementioned validity checking) that all the arguments in a default declaration must be type variables anyway. Therefore, creating the substitution is as simple as using `zipTvSubst`. I took the opportunity to perform this refactoring while I was in town. Fixes #13971.
* Be more careful when naming TyCon bindersSimon Peyton Jones2019-03-051-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch fixes two rather gnarly test cases: * Trac #16342 (mutual recursion) See Note [Tricky scoping in generaliseTcTyCon] * Trac #16221 (shadowing) See Note [Unification variables need fresh Names] The main changes are: * Substantial reworking of TcTyClsDecls.generaliseTcTyCon This is the big change, and involves the rather tricky function TcHsSyn.zonkRecTyVarBndrs. See Note [Inferring kinds for type declarations] and Note [Tricky scoping in generaliseTcTyCon] for the details. * bindExplicitTKBndrs_Tv and bindImplicitTKBndrs_Tv both now allocate /freshly-named/ unification variables. Indeed, more generally, unification variables are always fresh; see Note [Unification variables need fresh Names] in TcMType * Clarify the role of tcTyConScopedTyVars. See Note [Scoped tyvars in a TcTyCon] in TyCon As usual, this dragged in some more refactoring: * Renamed TcMType.zonkTyCoVarBndr to zonkAndSkolemise * I renamed checkValidTelescope to checkTyConTelescope; it's only used on TyCons, and indeed takes a TyCon as argument. * I folded the slightly-mysterious reportFloatingKvs into checkTyConTelescope. (Previously all its calls immediately followed a call to checkTyConTelescope.) It makes much more sense there. * I inlined some called-once functions to simplify checkValidTyFamEqn. It's less spaghetti-like now. * This patch also fixes Trac #16251. I'm not quite sure why #16251 went wrong in the first place, nor how this patch fixes it, but hey, it's good, and life is short.
* testsuite: Mark T5515 as broken with debugged compilerBen Gamari2019-02-071-1/+1
| | | | As noted in #16251.
* testsuite: Use makefile_testBen Gamari2019-01-301-6/+3
| | | | | This eliminates most uses of run_command in the testsuite in favor of the more structured makefile_test.
* Revert "Batch merge"Ben Gamari2019-01-301-3/+6
| | | | This reverts commit 76c8fd674435a652c75a96c85abbf26f1f221876.
* Batch mergeBen Gamari2019-01-301-6/+3
|
* Two tests for Trac #14230Simon Peyton Jones2018-11-301-0/+2
|
* Taming the Kind Inference MonsterSimon Peyton Jones2018-11-291-2/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | My original goal was (Trac #15809) to move towards using level numbers as the basis for deciding which type variables to generalise, rather than searching for the free varaibles of the environment. However it has turned into a truly major refactoring of the kind inference engine. Let's deal with the level-numbers part first: * Augment quantifyTyVars to calculate the type variables to quantify using level numbers, and compare the result with the existing approach. That is; no change in behaviour, just a WARNing if the two approaches give different answers. * To do this I had to get the level number right when calling quantifyTyVars, and this entailed a bit of care, especially in the code for kind-checking type declarations. * However, on the way I was able to eliminate or simplify a number of calls to solveEqualities. This work is incomplete: I'm not /using/ level numbers yet. When I subsequently get rid of any remaining WARNings in quantifyTyVars, that the level-number answers differ from the current answers, then I can rip out the current "free vars of the environment" stuff. Anyway, this led me into deep dive into kind inference for type and class declarations, which is an increasingly soggy part of GHC. Richard already did some good work recently in commit 5e45ad10ffca1ad175b10f6ef3327e1ed8ba25f3 Date: Thu Sep 13 09:56:02 2018 +0200 Finish fix for #14880. The real change that fixes the ticket is described in Note [Naughty quantification candidates] in TcMType. but I kept turning over stones. So this patch has ended up with a pretty significant refactoring of that code too. Kind inference for types and classes ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * Major refactoring in the way we generalise the inferred kind of a TyCon, in kcTyClGroup. Indeed, I made it into a new top-level function, generaliseTcTyCon. Plus a new Note to explain it Note [Inferring kinds for type declarations]. * We decided (Trac #15592) not to treat class type variables specially when dealing with Inferred/Specified/Required for associated types. That simplifies things quite a bit. I also rewrote Note [Required, Specified, and Inferred for types] * Major refactoring of the crucial function kcLHsQTyVars: I split it into kcLHsQTyVars_Cusk and kcLHsQTyVars_NonCusk because the two are really quite different. The CUSK case is almost entirely rewritten, and is much easier because of our new decision not to treat the class variables specially * I moved all the error checks from tcTyClTyVars (which was a bizarre place for it) into generaliseTcTyCon and/or the CUSK case of kcLHsQTyVars. Now tcTyClTyVars is extremely simple. * I got rid of all the all the subtleties in tcImplicitTKBndrs. Indeed now there is no difference between tcImplicitTKBndrs and kcImplicitTKBndrs; there is now a single bindImplicitTKBndrs. Same for kc/tcExplicitTKBndrs. None of them monkey with level numbers, nor build implication constraints. scopeTyVars is gone entirely, as is kcLHsQTyVarBndrs. It's vastly simpler. I found I could get rid of kcLHsQTyVarBndrs entirely, in favour of the bnew bindExplicitTKBndrs. Quantification ~~~~~~~~~~~~~~ * I now deal with the "naughty quantification candidates" of the previous patch in candidateQTyVars, rather than in quantifyTyVars; see Note [Naughty quantification candidates] in TcMType. I also killed off closeOverKindsCQTvs in favour of the same strategy that we use for tyCoVarsOfType: namely, close over kinds at the occurrences. And candidateQTyVars no longer needs a gbl_tvs argument. * Passing the ContextKind, rather than the expected kind itself, to tc_hs_sig_type_and_gen makes it easy to allocate the expected result kind (when we are in inference mode) at the right level. Type families ~~~~~~~~~~~~~~ * I did a major rewrite of the impenetrable tcFamTyPats. The result is vastly more comprehensible. * I got rid of kcDataDefn entirely, quite a big function. * I re-did the way that checkConsistentFamInst works, so that it allows alpha-renaming of invisible arguments. * The interaction of kind signatures and family instances is tricky. Type families: see Note [Apparently-nullary families] Data families: see Note [Result kind signature for a data family instance] and Note [Eta-reduction for data families] * The consistent instantation of an associated type family is tricky. See Note [Checking consistent instantiation] and Note [Matching in the consistent-instantation check] in TcTyClsDecls. It's now checked in TcTyClsDecls because that is when we have the relevant info to hand. * I got tired of the compromises in etaExpandFamInst, so I did the job properly by adding a field cab_eta_tvs to CoAxBranch. See Coercion.etaExpandCoAxBranch. tcInferApps and friends ~~~~~~~~~~~~~~~~~~~~~~~ * I got rid of the mysterious and horrible ClsInstInfo argument to tcInferApps, checkExpectedKindX, and various checkValid functions. It was horrible! * I got rid of [Type] result of tcInferApps. This list was used only in tcFamTyPats, when checking the LHS of a type instance; and if there is a cast in the middle, the list is meaningless. So I made tcInferApps simpler, and moved the complexity (not much) to tcInferApps. Result: tcInferApps is now pretty comprehensible again. * I refactored the many function in TcMType that instantiate skolems. Smaller things * I rejigged the error message in checkValidTelescope; I think it's quite a bit better now. * checkValidType was not rejecting constraints in a kind signature forall (a :: Eq b => blah). blah2 That led to further errors when we then do an ambiguity check. So I make checkValidType reject it more aggressively. * I killed off quantifyConDecl, instead calling kindGeneralize directly. * I fixed an outright bug in tyCoVarsOfImplic, where we were not colleting the tyvar of the kind of the skolems * Renamed ClsInstInfo to AssocInstInfo, and made it into its own data type * Some fiddling around with pretty-printing of family instances which was trickier than I thought. I wanted wildcards to print as plain "_" in user messages, although they each need a unique identity in the CoAxBranch. Some other oddments * Refactoring around the trace messages from reportUnsolved. * A bit of extra tc-tracing in TcHsSyn.commitFlexi This patch fixes a raft of bugs, and includes tests for them. * #14887 * #15740 * #15764 * #15789 * #15804 * #15817 * #15870 * #15874 * #15881
* More explicit foralls (GHC Proposal 0007)Matthew Yacavone2018-10-271-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | Allow the user to explicitly bind type/kind variables in type and data family instances (including associated instances), closed type family equations, and RULES pragmas. Follows the specification of GHC Proposal 0007, also fixes #2600. Advised by Richard Eisenberg. This modifies the Template Haskell AST -- old code may break! Other Changes: - convert HsRule to a record - make rnHsSigWcType more general - add repMaybe to DsMeta Includes submodule update for Haddock. Test Plan: validate Reviewers: goldfire, bgamari, alanz Subscribers: simonpj, RyanGlScott, goldfire, rwbarton, thomie, mpickering, carter GHC Trac Issues: #2600, #14268 Differential Revision: https://phabricator.haskell.org/D4894
* Allow scoped type variables refer to typesJoachim Breitner2018-08-051-1/+0
| | | | | | | | | | | | This patch implements GHC proposal 29: (sorry, URL is too long for the commit message linter) and fixess #15050. The change is simple: Just use a different meta variable form. Test suite and documentation updated. Differential Revision: https://phabricator.haskell.org/D4980
* Fix typechecking of kind signaturesSimon Peyton Jones2018-06-181-0/+1
| | | | | | | | | | | | | | | When typechecking a type like Maybe (a :: <kind-sig>) with a kind signature, we were using tc_lhs_kind to typecheck the signature. But that's utterly wrong; we need the signature to be fully solid (non unresolved equalities) before using it. In the case of Trac #14904 we went on to instantiate the kind signature, when it still had embedded unsolved constraints. This tripped the level-checking assertion when unifying a variable. The fix looks pretty easy to me: just call tcLHsKind instead. I had to add KindSigCtxt to
* Quantify unfixed kind variables in CUSKsRichard Eisenberg2018-06-151-1/+0
| | | | | | | | | | | | This is a small change in user-facing behavior. When we have a unification variable left over in a CUSK, we previously would issue an error. But, we can just quantify. This also teaches kcLHsQTyVars to use quantifyTyVars instead of its own, ad-hoc quantification scheme. Fixes #15273. test case: polykinds/T11648b
* Fix #13777 by improving the underdetermined CUSK error messageRyan Scott2018-06-021-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | The error message that GHC emits from underdetermined CUSKs is rather poor, since: 1. It may print an empty list of user-written variables if there are none in the declaration. 2. It may not mention any `forall`-bound, underdetermined variables in the result kind. To resolve these issues, this patch: 1. Doesn't bother printing a herald about user-written variables if there are none. 2. Prints the result kind to advertise any underdetermination it may exhibit. Test Plan: make test TEST=T13777 Reviewers: goldfire, bgamari Reviewed By: goldfire Subscribers: rwbarton, thomie, carter GHC Trac Issues: #13777 Differential Revision: https://phabricator.haskell.org/D4771
* Add regression test for #14246Ryan Scott2018-05-261-0/+1
|
* Clean up the conflicting data family instances error messageRyan Scott2018-05-241-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The way we were pretty-printing conflicting data family instances in an error message was far from ideal: 1. If a data type had no constructors, it would print an equals sign with nothing to the right of it. 2. It would try to print GADTs using Haskell98 syntax. 3. It eta-reduced away some type variables from the LHS. This patch addresses these three issues: 1. We no longer print constructors at all in this error message. There's really no reason to do so in the first place, since duplicate data family instances always conflict, regardless of their constructors. 2. Since we no longer print constructors, we no longer have to worry about whether we're using GADT or Haskell98 syntax. 3. I've put in a fix to ensure that type variables are no longer eta-reduced away from the LHS. Test Plan: make test TEST=T14179 Reviewers: goldfire, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #14179 Differential Revision: https://phabricator.haskell.org/D4711
* Check for type families in an instance contextSimon Peyton Jones2018-05-211-0/+1
| | | | | | This patch adds a check for type families to the instance-decl termination check. See Note [Type families in instance contexts] and Trac #15172.
* Fix #14369 by making injectivity warnings finer-grainedRyan Scott2017-10-191-0/+1
| | | | | | | | | | | | | | | | | | | | | Summary: Previously, GHC would always raise the possibility that a type family might not be injective in certain error messages, even if that type family actually //was// injective. Fix this by actually checking for a type family's lack of injectivity before emitting such an error message. Test Plan: ./validate Reviewers: goldfire, austin, bgamari, simonpj Reviewed By: simonpj Subscribers: simonpj, rwbarton, thomie GHC Trac Issues: #14369 Differential Revision: https://phabricator.haskell.org/D4106
* Tidying could cause ill-kinded typesSimon Peyton Jones2017-09-141-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I found (Trac #14175) that the tidying we do when reporting type error messages could cause a well-kinded type to become ill-kinded. Reason: we initialised the tidy-env with a completely un-zonked TidyEnv accumulated in the TcLclEnv as we come across lexical type-varialbe bindings. Solution: zonk them. But I ended up refactoring a bit: * Get rid of tcl_tidy :: TidyEnv altogether * Instead use tcl_bndrs :: TcBinderStack This used to contain only Ids, but now I've added those lexically scoped TyVars too. * Change names: TcIdBinderStack -> TcBinderStack TcIdBinder -> TcBinder extendTcIdBndrs -> extendTcBinderStack * Now tcInitTidyEnv can grab those TyVars from the tcl_bndrs, zonk, and tidy them. The only annoyance is that I had to add TcEnv.hs-boot, to break the recursion between the zonking code and the TrRnMonad functions like addErrTc that call tcInitTidyEnv. Tiresome, but in fact that file existed already.
* Fix #13972 by producing tidier errorsRyan Scott2017-08-171-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Previously, one could experience an error message like this: ``` Expected: T (a -> Either a b) Actual: T (a -> Either a b) ``` This makes the error message an iota clearer by tidying it first, which will instead produce: ``` Expected: T (a1 -> Either a1 b1) Actual: T (a -> Either a b) ``` Which steers users towards the understanding that the two sets of tyvars are actually different. Test Plan: make test TEST=T13972 Reviewers: simonpj, austin, bgamari, goldfire Reviewed By: goldfire Subscribers: goldfire, rwbarton, thomie GHC Trac Issues: #13972 Differential Revision: https://phabricator.haskell.org/D3820
* Fix #14045 by omitting an unnecessary checkRichard Eisenberg2017-07-291-0/+1
| | | | | | | | | | | | | | | | | | | | | | | Previously, we checked the number of patterns in a data instances for all data families whose kind did not end in a kind variable. But, of course, undersaturating instances can happen even without the kind ending in a kind variable. So I've omitted the arity check. Data families aren't as particular about their arity as type families are (because data families can be undersaturated). Still, this change degrades error messages when instances don't have the right arity; now, instead of reporting a simple mismatch in the number of patterns, GHC reports kind errors. The new errors are fully accurate, but perhaps not as easy to work with. Still, with the new flexibility of allowing data family instances with varying numbers of patterns, I don't see a better way. This commit also improves source fidelity in some error messages, requiring more changes than really are necessary. But without these changes, error messages around mismatched associated instance heads were poor. test cases: indexed-types/should_compile/T14045, indexed-types/should_fail/T14045a
* Add regression tests for #13601, #13780, #13877Ryan Scott2017-07-281-0/+1
| | | | | | | | | | | | | | | | | | | | | | Summary: Some recent commits happened to fix other issues: * c2417b87ff59c92fbfa8eceeff2a0d6152b11a47 fixed #13601 and #13780 * 8e15e3d370e9c253ae0dbb330e25b72cb00cdb76 fixed the original program in #13877 Let's add regression tests for each of these to ensure they stay fixed. Test Plan: make test TEST="T13601 T13780a T13780c T13877" Reviewers: goldfire, bgamari, austin Reviewed By: bgamari Subscribers: rwbarton, thomie GHC Trac Issues: #13601, #13780, #13877 Differential Revision: https://phabricator.haskell.org/D3794
* Test Trac #14033Simon Peyton Jones2017-07-261-0/+1
|
* Test Trac #13784Simon Peyton Jones2017-06-051-0/+1
|
* Re-engineer Given flatten-skolemsSimon Peyton Jones2017-05-261-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The big change here is to fix an outright bug in flattening of Givens, albeit one that is very hard to exhibit. Suppose we have the constraint forall a. (a ~ F b) => ..., (forall c. ....(F b)...) ... Then - we'll flatten the (F) b to a fsk, say (F b ~ fsk1) - we'll rewrite the (F b) inside the inner implication to 'fsk1' - when we leave the outer constraint we are suppose to unflatten; but that fsk1 will still be there - if we re-simplify the entire outer implication, we'll re-flatten the Given (F b) to, say, (F b ~ fsk2) Now we have two fsks standing for the same thing, and that is very wrong. Solution: make fsks behave more like fmvs: - A flatten-skolem is now a MetaTyVar, whose MetaInfo is FlatSkolTv - We "fill in" that meta-tyvar when leaving the implication - The old FlatSkol form of TcTyVarDetails is gone completely - We track the flatten-skolems for the current implication in a new field of InertSet, inert_fsks. See Note [The flattening story] in TcFlatten. In doing this I found various other things to fix: * I removed the zonkSimples from TcFlatten.unflattenWanteds; it wasn't needed. But I added one in TcSimplify.floatEqualities, which does the zonk precisely when it is needed. * Trac #13674 showed up a case where we had - an insoluble Given, e.g. a ~ [a] - the same insoluble Wanted a ~ [a] We don't use the Given to rewwrite the Wanted (obviously), but we therefore ended up reporting Can't deduce (a ~ [a]) from (a ~ [a]) which is silly. Conclusion: when reporting errors, make the occurs check "win" See Note [Occurs check wins] in TcErrors
* Testcase for type family consistency checksBartosz Nitka2017-05-221-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Based on my quick search, we don't have a test that verifies that we check the type family instances of currently compiled module against direct or indirect dependencies. This adds two tests: for a direct dependency and for an indirect dependency. I also added a comment to make it clear what the 'Over' test tests. Other than completeness, it makes sense to have these tests because if you look at Note [The type family instance consistency story] in FamInsts these cases are checked through different mechanisms. Test Plan: new tests Reviewers: simonmar, rwbarton, simonpj, austin, bgamari Reviewed By: simonpj, bgamari Subscribers: thomie GHC Trac Issues: #13719 Differential Revision: https://phabricator.haskell.org/D3602
* Allow associated types to pattern-match in non-class-bound variablesRyan Scott2017-03-141-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: After 8136a5cbfcd24647f897a2fae9fcbda0b1624035 (#11450), if you have a class with an associated type: ``` class C a where type T a b ``` And you try to create an instance of `C` like this: ``` instance C Int where type T Int Char = Bool ``` Then it is rejected, since you're trying to instantiate the variable ``b`` with something other than a type variable. But this restriction proves quite onerous in practice, as it prevents you from doing things like this: ``` class C a where type T a (b :: Identity c) :: c instance C Int where type T Int ('Identity x) = x ``` You have to resort to an auxiliary type family in order to define this now, which becomes extremely tiring. This lifts this restriction and fixes #13398, in which it was discovered that adding this restriction broke code in the wild. Test Plan: ./validate Reviewers: simonpj, bgamari, austin Reviewed By: simonpj Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3302
* tests: remove extra_files.py (#12223)Reid Barton2017-02-261-1/+1
| | | | | | | | | | | | The script I used is included as testsuite/driver/kill_extra_files.py, though at this point it is for mostly historical interest. Some of the tests in libraries/hpc relied on extra_files.py, so this commit includes an update to that submodule. One test in libraries/process also relies on extra_files.py, but we cannot update that submodule so easily, so for now we special-case it in the test driver.
* Test Trac #13271Simon Peyton Jones2017-02-221-0/+1
|
* Don't replace type family instances with the same LHS in GHCi (#7102)Reid Barton2017-02-051-0/+2
| | | | | | | | | | | | | | | | | | | | | This fixes the easy part of #7102 by removing the logic that lets the user replace a type family instance with a new one with the same LHS. As discussed on that ticket, this is unsound in general. Better to have the user redefine the type family from scratch. The example from comment:7 involving loading modules into ghci is not fixed yet; it actually doesn't rely on the instances having the same LHS. This commit adds an expect_broken test for that example as well. Test Plan: T7102a for the fix; T7102 is the test not fixed yet Reviewers: dfeuer, austin, bgamari, goldfire Reviewed By: dfeuer Subscribers: dfeuer, thomie Differential Revision: https://phabricator.haskell.org/D2994
* Remove clean_cmd and extra_clean usage from .T filesThomas Miedema2017-01-221-16/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | The `clean_cmd` and `extra_clean` setup functions don't do anything. Remove them from .T files. Created using https://github.com/thomie/refactor-ghc-testsuite. This diff is a test for the .T-file parser/processor/pretty-printer in that repository. find . -name '*.T' -exec ~/refactor-ghc-testsuite/Main "{}" \; Tests containing inline comments or multiline strings are not modified. Preparation for #12223. Test Plan: Harbormaster Reviewers: austin, hvr, simonmar, mpickering, bgamari Reviewed By: mpickering Subscribers: mpickering Differential Revision: https://phabricator.haskell.org/D3000 GHC Trac Issues: #12223
* Test Trac #12867Simon Peyton Jones2016-11-251-0/+1
|
* Allow TyVars in TcTypesSimon Peyton Jones2016-11-251-2/+1
| | | | | | | | | | | | | | | | | | | Up to now we've had a rule that a TyVar can't apppear in a type seen by the type checker; they should all be TcTyVars. But: a) With -XTypeInType it becomes much harder to exclude them; see Note [TcTyVars in the typechecker] in TcType. b) It's unnecessary to exculde them; instead we can just treat a TyVar just like vanillaSkolemTv. This is what was causing an ASSERT error in indexed-types/should_fail/T12041, reported in Trac #12826. That patch allows a TyVar in a TcType. The most significant change is to make Var.tcTyVarDetails return vanillaSkolemTv. In fact it already did, but (a) it was not documented, and (b) we never exploited it. Now we rely on it.
* Mark T12041 as expect_broken with -DDEBUG (#12826)Simon Marlow2016-11-151-1/+2
|
* Prevent GND from inferring an instance context for method-less classesRyan Scott2016-11-101-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When `GeneralizedNewtypeDeriving` is used with a type class that has no methods, it will generate a redundant context, and as a result, it can trigger warnings when compiled with `-Wredundant-constraints`. This is a simple change in behavior to check beforehand if a class has methods when deriving it with GND, and if it has no methods, avoid inferring the redundant context. Beware that the test for #6088, which used to be expected to fail, now compiles without issue since it doesn't infer a problematic instance context. Thanks to Simon Peyton Jones for doing the necessary refactoring in f05d685ae05ec293083f2fa7ec7ba057fbe64869. Fixes #12814. Test Plan: ./validate Reviewers: goldfire, rwbarton, simonpj, austin, bgamari Reviewed By: simonpj Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2692 GHC Trac Issues: #12814
* More tests for Trac #12522Simon Peyton Jones2016-10-101-0/+1
| | | | These ones test the variations in coment:15 of the ticket
* Testsuite: run all indexed-types ways on ./validate --slowThomas Miedema2016-06-281-2/+0
| | | | I don't know why some ways were omitted before.
* Improve pretty-printing of equalitiesSimon Peyton Jones2016-05-191-0/+1
| | | | | The previous pretty-printer didn't account for partially applied equalities, causing Trac #12041
* Tighten checking for associated type instancesSimon Peyton Jones2016-04-191-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch finishes off Trac #11450. Following debate on that ticket, the patch tightens up the rules for what the instances of an associated type can look like. Now they must match the instance header exactly. Eg class C a b where type T a x b With this class decl, if we have an instance decl instance C ty1 ty2 where ... then the type instance must look like type T ty1 v ty2 = ... with exactly - 'ty1' for 'a' - 'ty2' for 'b', and - a variable for 'x' For example: instance C [p] Int type T [p] y Int = (p,y,y) Previously we allowed multiple instance equations and now, in effect, we don't since they would all overlap. If you want multiple cases, use an auxiliary type family. This is consistent with the treatment of generic-default instances, and the user manual always said "WARNING: this facility (multiple instance equations may be withdrawn in the future". I also improved error messages, and did other minor refactoring.
* Prevent eager unification with type families.Richard Eisenberg2016-03-211-0/+1
| | | | | See Note [Prevent unification with type families] in TcUnify for the details.
* Allow eager unification with type families.Richard Eisenberg2016-03-141-1/+0
| | | | | | | | | | | | | | | | | | | | Previously, checkTauTvUpdate, used in the eager unifier (TcUnify) right before writing to a metavar, refused to write a metavar to a type involving type functions. The reason for this was given in a Note, but the Note didn't make all that much sense and even admitted that it was a bit confused. The Note, in turn, referred to another Note, which it was quite sceptical of, as well. The type-family check was slowing down performance, so I tried removing it, running the tests referred to in the Note. The tests all passed without the check. Looking at more test results, I saw several error messages improve without the check, and some cases where GHC looped (T7788, in particular) it now doesn't. So, all in all, quite a win: Two hairy Notes removed, several lines of code removed, better performance, and improved output. [skip ci]
* Check arity on default decl for assoc typesSimon Peyton Jones2015-11-271-0/+1
| | | | | | Fixes Trac #11136. We should check arity before doing tcTyClTyVars, because the latter crahes if the arity isn't right.
* Perform a validity check on assoc type defaults.Richard Eisenberg2015-09-211-0/+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}
* Testsuite: delete remaining only_compiler_types(['ghc']) setupsThomas Miedema2015-07-141-1/+0
| | | | | No point in pretending other compilers can use the GHC testsuite. This makes the *.T files a bit shorter.
* Testsuite: delete expect_fail setups for ghc < 7.1Thomas Miedema2015-06-091-1/+1
| | | | | | This makes it easier to grep for expect_fail in the tests directory. Differential Revision: https://phabricator.haskell.org/D965
View Lorry Controller Status