- 18 May, 2016 1 commit
-
-
niteria authored
The order inert_model and intert_eqs fold affects the order that the typechecker looks at things. I've been able to experimentally confirm that the order of equalities and the order of the model matter for determinism. This is just a straigthforward replacement of nondeterministic VarEnv for deterministic DVarEnv. Test Plan: ./validate Reviewers: simonpj, goldfire, austin, bgamari, simonmar Reviewed By: simonmar Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2232 GHC Trac Issues: #4012
-
- 22 Apr, 2016 1 commit
-
-
Simon Peyton Jones authored
-
- 15 Apr, 2016 1 commit
-
-
Simon Peyton Jones authored
This patch tides up the structure, simplifying FlattenTvResult. It also replaces a use of zonkTcType (which I hated) with coercionKind, in that same function. Happily, the result is little faster, maybe even a percentage point or two, which is a lot for a compiler. This also removes the line || not (map binderVisibility bndrs1 == map binderVisibility bndrs2) from TcCanonical.can_eq_nc', in the ForAllTy/ForAllTy case. Why? Becuase I can't see why binder-visiblity should matter, and when we use coercionKind instead of zonkTcType in flattenTyVar, this case pops up and rejects a program that should pass. I did discuss this with Richard.
-
- 21 Mar, 2016 2 commits
-
-
eir@cis.upenn.edu authored
-
eir@cis.upenn.edu authored
-
- 17 Mar, 2016 1 commit
-
-
eir@cis.upenn.edu authored
There were several smallish bugs here: - We had too small an InScopeSet when rejigging GADT return types. - When adding the extra_tvs with a datatype kind signature, we were sometimes changing Uniques of an explicitly bound kind var. - Using coercionKind in the flattener got the wrong visibility for a binder. Now we just zonk to get what we need. Test case: dependent/should_compile/RaeJobTalk
-
- 08 Feb, 2016 2 commits
-
-
Simon Peyton Jones authored
tyConRolesRepresentational is just a version of tyConRolesX, but specialised for a Representational argument. Saves a bit of extra argument passing and pattern matching, and tyConRolesX was often called when we knew the argument role was Representational. Rather to my surprise this made the compiler allocate 5% less for tests T9872{b,c,d}. At least I think it's this commit. Good thing, regardless.
-
Simon Peyton Jones authored
They were excessively verbose. I've commented them out rather than deleting so that they can easily be restored.
-
- 27 Jan, 2016 1 commit
-
-
niteria authored
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
-
- 26 Jan, 2016 1 commit
-
-
niteria authored
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
-
- 19 Jan, 2016 1 commit
-
-
niteria authored
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
-
- 18 Jan, 2016 1 commit
-
-
Jan Stolarek authored
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
-
- 16 Jan, 2016 1 commit
-
-
Simon Peyton Jones authored
As a result of some other unrelated changes I found that IndTypesPerf was failing, and opened Trac #11408. There's a test in indexed-types/should-compile/T11408. The bug was that a type like forall t. (MT (UL t) (UR t) ~ t) => UL t -> UR t -> Int is in fact unambiguous, but it's a bit subtle to prove that it is unambiguous. In investigating, Dimitrios and I found several subtle bugs in the constraint solver, fixed by this patch * canRewrite was missing a Derived/Derived case. This was lost by accident in Richard's big kind-equality patch. * Interact.interactTyVarEq would discard [D] a ~ ty if there was a [W] a ~ ty in the inert set. But that is wrong because the former can rewrite things that the latter cannot. Fix: a new function eqCanDischarge * In TcSMonad.addInertEq, the process was outright wrong for a Given/Wanted in the (GWModel) case. We were adding a new Derived without kicking out things that it could rewrite. Now the code is simpler (no special GWModel case), and works correctly. * The special case in kickOutRewritable for [W] fsk ~ ty, turns out not to be needed. (We emit a [D] fsk ~ ty which will do the job. I improved comments and documentation, esp in TcSMonad.
-
- 31 Dec, 2015 2 commits
-
-
Herbert Valerio Riedel authored
Starting with GHC 7.10 and base-4.8, `Monad` implies `Applicative`, which allows to simplify some definitions to exploit the superclass relationship. This a first refactoring to that end.
-
Herbert Valerio Riedel authored
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
-
- 11 Dec, 2015 1 commit
-
-
eir@cis.upenn.edu authored
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.
-
- 17 Oct, 2015 1 commit
-
-
Herbert Valerio Riedel authored
This patch refactors pure/(*>) and return/(>>) in MRP-friendly way, i.e. such that the explicit definitions for `return` and `(>>)` match the MRP-style default-implementation, i.e. return = pure and (>>) = (*>) This way, e.g. all `return = pure` definitions can easily be grepped and removed in GHC 8.1; Test Plan: Harbormaster Reviewers: goldfire, alanz, bgamari, quchen, austin Reviewed By: quchen, austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1312
-
- 21 Sep, 2015 1 commit
-
-
eir@cis.upenn.edu authored
This fixes #10896. In the indexed-types/should_fail/BadSock test, there is a bad type definition. This gets type-checked, an error gets reported, but then **GHC keeps going**. Later, when running the simplifier to do an ambiguity check, the bad type environment causes GHC to fall over. My solution: only run the simplifier in a clean, error-free type environment. A downside of this is that fewer error messages are reported. This makes me a bit sad, but I'm not sure how to avoid the problem. Suggestions welcome.
-
- 07 Aug, 2015 1 commit
-
-
Simon Peyton Jones authored
-
- 15 Jul, 2015 1 commit
-
-
eir@cis.upenn.edu authored
Representational equalities cannot discharge nominal ones. Even if, somehow, this didn't cause a type error (as reported in the ticket), it would surely cause a core lint error.
-
- 11 Jun, 2015 1 commit
-
-
Simon Peyton Jones authored
I wasn't very happy with my fix to Trac #10009. This is much better. The main idea is that the inert set now contains a "model", which embodies *all* the (nominal) equalities that we know about, with a view to exposing unifications. This requires a lot fewer iterations of the solver than before. There are extensive comments in TcSMonad: Note [inert_model: the inert model] Note [Adding an inert canonical constraint the InertCans] The big changes are * New inert_model field in InertCans * Functions addInertEq, addInertCan deal with adding a constraint, maintaining the model * A nice improvement is that unification variables can unify with fmvs, so that from, say alpha ~ fmv we get alpha := fmv See Note [Orientation of equalities with fmvs] in TcFlatten It's still not perfect, as the Note explains New flag -fconstraint-solver-iterations=n, allows us to control the number of constraint solver iterations, and in particular will flag up when it's more than a small number. Performance is generally slightly better: T5837 is a lot better for some reason.
-
- 07 May, 2015 1 commit
-
-
Simon Peyton Jones authored
-
- 01 May, 2015 1 commit
-
-
Simon Peyton Jones authored
See Note [Deriveds do rewrite Deriveds]. The important point is that we want to maintain the Note [Can-rewrite relation] property, lest we risk loops.
-
- 29 Apr, 2015 2 commits
-
-
Simon Peyton Jones authored
This regrettably-big patch substantially improves the way in which "improvement" happens in the constraint solver. It was triggered by trying to crack Trac #10009, but it turned out to solve #10340 as well. The big picture, with several of the trickiest examples, is described in Note [The improvement story] in TcInteract. The major change is this: * After solving we explicitly try "improvement", by - making the unsolved Wanteds into Deriveds - allowing Deriveds to rewrite Deriveds This more aggressive rewriting "unlocks" some extra guess-free unifications. * The main loop is in TcInteract.solveSimpleWanteds, but I also ended up refactoring TcSimplify.simpl_loop, and its surrounding code. Notably, any insolubles from the Givens are pulled out and treated separately, rather than staying in the inert set during the solveSimpleWanteds loop. There are a lot of follow-on changes * Do not emit generate Derived improvements from Wanteds. This saves work in the common case where they aren't needed. * For improvement we should really do type-class reduction on Derived constraints in doTopReactDict. That entailed changing the GenInst constructor a bit; a local and minor change * Some annoying faffing about with dropping derived constraints; see dropDerivedWC, dropDerivedSimples, dropDerivedInsols, and their Notes. * Some substantial refactoring in TcErrors.reportWanteds. This work wasn't strictly forced, but I got sucked into it. All the changes are in TcErrors. * Use TcS.unifyTyVar consistently, rather than setWantedTyBind, so that unifications are properly tracked. * Refactoring around solveWantedsTcM, solveWantedsAndDrop. They previously guaranteed a zonked result, but it's more straightforward for clients to zonk.
-
Simon Peyton Jones authored
Because when flattening a Derived constraint, the evidence doesn't exist (it's an error thunk)
-
- 22 Apr, 2015 1 commit
-
-
Simon Peyton Jones authored
-
- 14 Apr, 2015 1 commit
-
-
Simon Peyton Jones authored
-
- 23 Mar, 2015 1 commit
-
-
eir@cis.upenn.edu authored
This implements (roughly) the plan put forward in comment:14:ticket:7788, fixing #7788, #8550, #9554, #10139, and addressing concerns raised in #10079. There are some regressions w.r.t. GHC 7.8, but only with pathological type families (like F a = F a). This also (hopefully -- don't have a test case) fixes #10158. Unsolved problems include #10184 and #10185, which are both known deficiencies of the approach used here. As part of this change, the plumbing around detecting infinite loops has changed. Instead of -fcontext-stack and -ftype-function-depth, we now have one combined -freduction-depth parameter. Setting it to 0 disbales the check, which is now the recommended way to get (terminating) code to typecheck in releases. (The number of reduction steps may well change between minor GHC releases!) This commit also introduces a new IntWithInf type in BasicTypes that represents an integer+infinity. This type is used in a few places throughout the code. Tests in indexed-types/should_fail/T7788 indexed-types/should_fail/T8550 indexed-types/should_fail/T9554 indexed-types/should_compile/T10079 indexed-types/should_compile/T10139 typecheck/should_compile/T10184 (expected broken) typecheck/should_compile/T10185 (expected broken) This commit also changes performance testsuite numbers, for the better.
-
- 02 Mar, 2015 1 commit
-
-
Simon Peyton Jones authored
This is minor stuff triggered by Trac #10103. * Fix outdated comments on tcView/coreView (we should really combine them with a new name, but I'll leave that slightly-disruptive change for now) * Combine tcExpandTyCon_maybe and coreExpandTyCon_maybe (which were identical) into expandSynTyCon_maybe * A few more comment fixups
-
- 20 Feb, 2015 1 commit
-
-
Simon Peyton Jones authored
-
- 09 Jan, 2015 1 commit
-
-
Simon Peyton Jones authored
Particularly, flatten_many was exported, but the caller was not doing runFlatten. Moreover it was always used at nominal role. This patch makes the API clearer, and more robust
-
- 06 Jan, 2015 1 commit
-
-
Simon Peyton Jones authored
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
-
- 23 Dec, 2014 1 commit
-
-
Simon Peyton Jones authored
-
- 22 Dec, 2014 1 commit
-
-
eir@cis.upenn.edu authored
-
- 20 Dec, 2014 1 commit
-
-
eir@cis.upenn.edu authored
This has a demonstrated 2x speed boost on the T9872{a,b,c} tests. (#9872)
-
- 17 Dec, 2014 1 commit
-
-
eir@cis.upenn.edu authored
This commit fixes some performance regressions introduced by 0cc47eb9, adding more `Coercible` magic to the solver. See Note [flatten_many performance] in TcFlatten for more info. The improvements do not quite restore the old numbers. Given that the solver is really more involved now, I am accepting this regression. The way forward (I believe) would be to have *two* flatteners: one that deals only with nominal equalities and thus never checks roles, and the more general one. A nice design of keeping this performant without duplicating code eludes me, but someone else is welcome to take a stab.
-
- 12 Dec, 2014 1 commit
-
-
eir@cis.upenn.edu authored
Summary: This is a rewrite of the algorithm to solve for Coercible "instances". A preliminary form of these ideas is at https://ghc.haskell.org/trac/ghc/wiki/Design/NewCoercibleSolver The basic idea here is that the `EqPred` constructor of `PredTree` now is parameterised by a new type `EqRel` (where `data EqRel = NomEq | ReprEq`). Thus, every equality constraint can now talk about nominal equality (the usual case) or representational equality (the `Coercible` case). This is a change from the previous behavior where `Coercible` was just considered a regular class with a special case in `matchClassInst`. Because of this change, representational equalities are now canonicalized just like nominal ones, allowing more equalities to be solved -- in particular, the case at the top of #9117. A knock-on effect is that the flattener must be aware of the choice of equality relation, because the inert set now stores both representational inert equalities alongside the nominal inert equalities. Of course, we can use representational equalities to rewrite only within another representational equality -- thus the parameterization of the flattener. A nice side effect of this change is that I've introduced a new type `CtFlavour`, which tracks G vs. W vs. D, removing some ugliness in the flattener. This commit includes some refactoring as discussed on D546. It also removes the ability of Deriveds to rewrite Deriveds. This fixes bugs #9117 and #8984. Reviewers: simonpj, austin, nomeata Subscribers: carter, thomie Differential Revision: https://phabricator.haskell.org/D546 GHC Trac Issues: #9117, #8984
-
- 11 Dec, 2014 1 commit
-
-
Simon Peyton Jones authored
-
- 10 Dec, 2014 2 commits
-
-
Simon Peyton Jones authored
-
Simon Peyton Jones authored
This short-cut can improve performance quite a bit, by short-circuiting the process of creating a fresh constraint and binding for each reduction. See Note [Reduce type family applications eagerly] in TcFlatten To do this I had to generalise the inert_flat_cache a bit, so that the rhs is not necessarily a type variable; but nothing fundamental.
-