summaryrefslogtreecommitdiff
path: root/testsuite/tests
Commit message (Collapse)AuthorAgeFilesLines
* testsuite: Bump a performance testsBen Gamari2017-02-231-32/+35
| | | | | | | T5321Fun, T3064, and T12707 are failing, but only on Darwin. I suspect this is probably creep from Typeable and pushed over the edge by some of Simon's recent commits. Unfortunately the tree brokenness due to the recent submodule bumps makes it difficult to pin down.
* Revert recent submodule bumpsBen Gamari2017-02-227-14/+12
| | | | | | | | They broke everything and the solution will be non-trivial. This reverts commit 8ccbc2e5252abd4fa67d155d4fff489ee9929906. This reverts commit c8d995db5d743358b0583fe97f8113bf9047641e. This reverts commit 7153370288e6075c4f8c996ff02227e48805da06.
* Test Trac #13244Simon Peyton Jones2017-02-222-0/+35
|
* Fix ApplicativeDo constraint scopingSimon Peyton Jones2017-02-222-0/+17
| | | | | | | | This patch fixes Trac #13242, by a bit of fancy footwork with the LIE variable in which the WantedConstraints are collected. I think it can be simplified further, using a 'map'.
* Test Trac #13271Simon Peyton Jones2017-02-223-0/+18
|
* Bump Cabal and containers submodulesBen Gamari2017-02-217-12/+14
|
* Fix all broken perf tests on x64 WindowsTamar Christina2017-02-215-6/+29
| | | | | | | | | | | | | various perf tests have been broken over the course of the past few months. This updates the numbers. Test Plan: ./validate Reviewers: austin, bgamari Subscribers: thomie, #ghc_windows_task_force Differential Revision: https://phabricator.haskell.org/D3160
* Test Trac #13300Simon Peyton Jones2017-02-213-0/+17
|
* Gather constraints locally in checkMainSimon Peyton Jones2017-02-214-0/+34
| | | | | | | | Wiwth -fdefer-type-errors we were generating some top-level equality constraints, just in a corner of checkMain. The fix is easy. Fixes Trac #13292
* Disallow class instances for synonymsSimon Peyton Jones2017-02-213-0/+21
| | | | | | | | See Trac #13267 and Note [Instances and constraint synonyms] in TcValidity. We can't easily do a perfect job, because the rename is really trying to do its lookup too early. But this is at least an improvement.
* testsuite: Fix allocations of T10547Ben Gamari2017-02-211-1/+1
| | | | | Previously the comment was correct, but the expected value itself was never updated.
* Fix computation of dfun_tvs in mkNewTypeEqnSimon Peyton Jones2017-02-212-0/+10
| | | | | | | | This bug was causing Trac #13297. We were recomputing ds_tvs, and doing it wrongly (by omitting variables that appear only in mtheta). But actually plain 'tvs' is just fine. So code deleted, and bug fixed.
* Fix DeriveAnyClass (again)Simon Peyton Jones2017-02-213-0/+46
| | | | | | | | | | | This patch fixes Trac #13272. The general approach was fine, but we were simply not generating the correct implication constraint (in particular generating fresh unification variables). I added a lot more commentary to Note [Gathering and simplifying constraints for DeriveAnyClass] I'm still not very happy with the overall architecture. It feels more complicate than it should.
* Bump a few more performance regressions from Type-indexed TypeableBen Gamari2017-02-201-2/+4
| | | | | These are right on the edge of acceptance and are only reproducible on a stressed machine.
* Bump Cabal submoduleBen Gamari2017-02-204-10/+13
| | | | We are now tracking the 2.0 branch.
* Kill off the remaining Rec []Simon Peyton Jones2017-02-201-30/+30
| | | | | | | The desugarer was producing an empty Rec group, which is never supposed to happen. This small patch stops that happening. Next up: Lint should check.
* Change -dppr-ticks to -dsuppress-ticksSimon Peyton Jones2017-02-201-2/+2
| | | | | | | | | | | | | | | | I spent about two hours today hunting fruitlessly for a simplifier bug (when fixing Trac #13255), only to find that it was caused by -ddump-X silently suppressing all ticks in Core. I think this has happened to me once before. So I've changed to make tick-printing on by default (like coercions, etc), with a flag -dsuppress-ticks (like -dsuppress-coercions) to suppress them. Blargh. -dppr-ticks is still there, but deprecated.
* Typos in manual, tests and commentsGabor Greif2017-02-203-3/+3
|
* Remove ghc-api/landmine testsAlan Zimmerman2017-02-199-206/+0
| | | | | They take a long time to run, and are effectively superseded by the -ddump-*-ast tests.
* Disable Typeable binding generation for unboxed sumsBen Gamari2017-02-182-4/+4
| | | | | These things are simply too expensive to generate at the moment. More work is needed here; see #13276 and #13261.
* Type-indexed TypeableBen Gamari2017-02-1837-374/+1176
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This at long last realizes the ideas for type-indexed Typeable discussed in A Reflection on Types (#11011). The general sketch of the project is described on the Wiki (Typeable/BenGamari). The general idea is that we are adding a type index to `TypeRep`, data TypeRep (a :: k) This index allows the typechecker to reason about the type represented by the `TypeRep`. This index representation mechanism is exposed as `Type.Reflection`, which also provides a number of patterns for inspecting `TypeRep`s, ```lang=haskell pattern TRFun :: forall k (fun :: k). () => forall (r1 :: RuntimeRep) (r2 :: RuntimeRep) (arg :: TYPE r1) (res :: TYPE r2). (k ~ Type, fun ~~ (arg -> res)) => TypeRep arg -> TypeRep res -> TypeRep fun pattern TRApp :: forall k2 (t :: k2). () => forall k1 (a :: k1 -> k2) (b :: k1). (t ~ a b) => TypeRep a -> TypeRep b -> TypeRep t -- | Pattern match on a type constructor. pattern TRCon :: forall k (a :: k). TyCon -> TypeRep a -- | Pattern match on a type constructor including its instantiated kind -- variables. pattern TRCon' :: forall k (a :: k). TyCon -> [SomeTypeRep] -> TypeRep a ``` In addition, we give the user access to the kind of a `TypeRep` (#10343), typeRepKind :: TypeRep (a :: k) -> TypeRep k Moreover, all of this plays nicely with 8.2's levity polymorphism, including the newly levity polymorphic (->) type constructor. Library changes --------------- The primary change here is the introduction of a Type.Reflection module to base. This module provides access to the new type-indexed TypeRep introduced in this patch. We also continue to provide the unindexed Data.Typeable interface, which is simply a type synonym for the existentially quantified SomeTypeRep, data SomeTypeRep where SomeTypeRep :: TypeRep a -> SomeTypeRep Naturally, this change also touched Data.Dynamic, which can now export the Dynamic data constructor. Moreover, I removed a blanket reexport of Data.Typeable from Data.Dynamic (which itself doesn't even import Data.Typeable now). We also add a kind heterogeneous type equality type, (:~~:), to Data.Type.Equality. Implementation -------------- The implementation strategy is described in Note [Grand plan for Typeable] in TcTypeable. None of it was difficult, but it did exercise a number of parts of the new levity polymorphism story which had not yet been exercised, which took some sorting out. The rough idea is that we augment the TyCon produced for each type constructor with information about the constructor's kind (which we call a KindRep). This allows us to reconstruct the monomorphic result kind of an particular instantiation of a type constructor given its kind arguments. Unfortunately all of this takes a fair amount of work to generate and send through the compilation pipeline. In particular, the KindReps can unfortunately get quite large. Moreover, the simplifier will float out various pieces of them, resulting in numerous top-level bindings. Consequently we mark the KindRep bindings as noinline, ensuring that the float-outs don't make it into the interface file. This is important since there is generally little benefit to inlining KindReps and they would otherwise strongly affect compiler performance. Performance ----------- Initially I was hoping to also clear up the remaining holes in Typeable's coverage by adding support for both unboxed tuples (#12409) and unboxed sums (#13276). While the former was fairly straightforward, the latter ended up being quite difficult: while the implementation can support them easily, enabling this support causes thousands of Typeable bindings to be emitted to the GHC.Types as each arity-N sum tycon brings with it N promoted datacons, each of which has a KindRep whose size which itself scales with N. Doing this was simply too expensive to be practical; consequently I've disabled support for the time being. Even after disabling sums this change regresses compiler performance far more than I would like. In particular there are several testcases in the testsuite which consist mostly of types which regress by over 30% in compiler allocations. These include (considering the "bytes allocated" metric), * T1969: +10% * T10858: +23% * T3294: +19% * T5631: +41% * T6048: +23% * T9675: +20% * T9872a: +5.2% * T9872d: +12% * T9233: +10% * T10370: +34% * T12425: +30% * T12234: +16% * 13035: +17% * T4029: +6.1% I've spent quite some time chasing down the source of this regression and while I was able to make som improvements, I think this approach of generating Typeable bindings at time of type definition is doomed to give us unnecessarily large compile-time overhead. In the future I think we should consider moving some of all of the Typeable binding generation logic back to the solver (where it was prior to 91c6b1f54aea658b0056caec45655475897f1972). I've opened #13261 documenting this proposal.
* Generalize kind of the (->) tyconBen Gamari2017-02-189-16/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is generalizes the kind of `(->)`, as discussed in #11714. This involves a few things, * Generalizing the kind of `funTyCon`, adding two new `RuntimeRep` binders, ```lang=haskell (->) :: forall (r1 :: RuntimeRep) (r2 :: RuntimeRep) (a :: TYPE r1) (b :: TYPE r2). a -> b -> * ``` * Unsaturated applications of `(->)` are expressed as explicit `TyConApp`s * Saturated applications of `(->)` are expressed as `FunTy` as they are currently * Saturated applications of `(->)` are expressed by a new `FunCo` constructor in coercions * `splitTyConApp` needs to ensure that `FunTy`s are split to a `TyConApp` of `(->)` with the appropriate `RuntimeRep` arguments * Teach CoreLint to check that all saturated applications of `(->)` are represented with `FunTy` At the moment I assume that `Constraint ~ *`, which is an annoying source of complexity. This will be simplified once D3023 is resolved. Also, this introduces two known regressions, `tcfail181`, `T10403` ===================== Only shows the instance, instance Monad ((->) r) -- Defined in ‘GHC.Base’ in its error message when -fprint-potential-instances is used. This is because its instance head now mentions 'LiftedRep which is not in scope. I'm not entirely sure of the right way to fix this so I'm just accepting the new output for now. T5963 (Typeable) ================ T5963 is now broken since Data.Typeable.Internals.mkFunTy computes its fingerprint without the RuntimeRep variables that (->) expects. This will be fixed with the merge of D2010. Haddock performance =================== The `haddock.base` and `haddock.Cabal` tests regress in allocations by about 20%. This certainly hurts, but it's also not entirely unexpected: the size of every function type grows with this patch and Haddock has a lot of functions in its heap.
* Say 'data' explicitly in IfAbstractTyCon output.Edward Z. Yang2017-02-1710-11/+11
| | | | Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
* Improvements/bugfixes to signature reexport handling.Edward Z. Yang2017-02-1712-6/+70
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: A number of changes: - Keep the TcGblEnv from typechecking the local signature around when we do merging. In particular, we setup tcg_imports and tcg_rdr_env according to the local signature. This improves our error output (for example, see bkpfail04) and also fixes a bug with reexporting modules in signatures (see bkpreex07) - Fix a bug in thinning, where if we had signature A(module A), this previously would have *thinned out* all of the inherited signatures. Now we treat every inherited signature as having come from an import like "import A", so a module A reexport will pick them up. - Recompilation checking now keeps track of dependent source files of the source signature; previously we forgot to retain this info. There's a manual update too. Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu> Test Plan: validate Reviewers: bgamari, austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D3133
* Fix recompilation tracking on signatures.Edward Z. Yang2017-02-179-0/+61
| | | | | | | | | | | | | | | | | | Summary: Previously we weren't tracking these dependencies at all, because we couldn't "find" the interface for {A.H}. Now we've associated hole names to the correct module identity so we will pick them up. Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu> Test Plan: validate Reviewers: bgamari, austin Subscribers: thomie, snowleopard Differential Revision: https://phabricator.haskell.org/D3131
* Fix a Backpack recompilation avoidance bug when signatures change.Edward Z. Yang2017-02-1710-1/+84
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Recompilation avoidance checks if -this-unit-id has changed by relying on the "wanted module" check in readIface ("Something is amiss..."). Unfortunately, this check didn't check if the instantiation made sense, which meant that if you changed the signatures of a Backpack package, we'd still treat the old signatures as up-to-date. The way I fixed this was by having findAndReadIface take in a 'Module' representing the /actual/ module we were intending to lookup. We convert this into the 'Module' we expect to see in 'mi_module' and now do a more elaborate check that will also verify that instantiations make sense. Along the way, I robustified the logging infrastructure for recompilation checking, and folded wrongIfaceModErr (which was dead code) into the error message. Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu> Test Plan: validate Reviewers: bgamari, austin Subscribers: thomie, snowleopard Differential Revision: https://phabricator.haskell.org/D3130
* Simplify OutputableBndrSimon Peyton Jones2017-02-174-43/+43
| | | | | | | | | This replaces three methods in OutputableBndr with one, and adds comments. There's also a tiny change in the placement of equals signs in debug-prints. I like it better that way, but if it complicates life for anyone we can put it back.
* Honour -dsuppress-uniques more thoroughlySimon Peyton Jones2017-02-174-40/+40
| | | | | | | | | | | I found that tests parser/should_compile/DumpRenamedAst and friends were printing uniques, which makes the test fragile. But -dsuppress-uniques made no difference! It turned out that pprName wasn't properly consulting Opt_SuppressUniques. This patch fixes the problem, and updates those three tests to use -dsuppress-uniques
* Better perf for haddock.base, haddock.CabalSimon Peyton Jones2017-02-161-2/+4
| | | | | | | | | | | I think this is due to commit 6bab649bde653f13c15eba30d5007bef4a9a9d3a Author: Simon Peyton Jones <simonpj@microsoft.com> Date: Thu Feb 16 09:42:32 2017 +0000 Improve checking of joins in Core Lint Improvement is around 5%.
* Use the correct origin in SectionL and Section RSimon Peyton Jones2017-02-164-1/+16
| | | | | | | | | This fixes Trac #13285. The CallStack stuff is all driven by a CtOrigin of (OccurenceOf f), and we were instead using SectionOrigin. Boo! Easily fixed; and I did a little refactoring as usual.
* Typos [ci skip]Gabor Greif2017-02-152-3/+3
|
* Don't warn about missing methods for instances in signatures.Edward Z. Yang2017-02-143-0/+16
| | | | | | | | | | | | Test Plan: validate Reviewers: bgamari, austin, dfeuer Reviewed By: dfeuer Subscribers: dfeuer, thomie Differential Revision: https://phabricator.haskell.org/D3134
* Check local type family instances against all imported onesReid Barton2017-02-1420-2/+135
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We previously checked type family instance declarations in a module for consistency with all instances that we happened to have read into the EPS or HPT. It was possible to arrange that an imported type family instance (used by an imported function) was in a module whose interface file was never read during compilation; then we wouldn't check consistency of local instances with this imported instance and as a result type safety was lost. With this patch, we still check consistency of local type family instances with all type family instances that we have loaded; but we make sure to load the interface files of all our imports that define family instances first. More selective consistency checking is left to #13102. On the other hand, we can now safely assume when we import a module that it has been checked for consistency with its imports. So we can save checking in checkFamInstConsistency, and overall we should have less work to do now. This patch also adds a note describing the Plan for ensuring type family consistency. Test Plan: Two new tests added; harbormaster Reviewers: austin, simonpj, bgamari Reviewed By: simonpj, bgamari Subscribers: ggreif, thomie Differential Revision: https://phabricator.haskell.org/D2992
* Implement HasField constraint solving and modify OverloadedLabelsAdam Gundry2017-02-1431-27/+315
| | | | | | | | | | | | | | | | | | | | | | | | | This implements automatic constraint solving for the new HasField class and modifies the existing OverloadedLabels extension, as described in the GHC proposal (https://github.com/ghc-proposals/ghc-proposals/pull/6). Per the current form of the proposal, it does *not* currently introduce a separate `OverloadedRecordFields` extension. This replaces D1687. The users guide documentation still needs to be written, but I'll do that after the implementation is merged, in case there are further design changes. Test Plan: new and modified tests in overloadedrecflds Reviewers: simonpj, goldfire, dfeuer, bgamari, austin, hvr Reviewed By: bgamari Subscribers: maninalift, dfeuer, ysangkok, thomie, mpickering Differential Revision: https://phabricator.haskell.org/D2708
* Allow type defaulting for multi-param type classes with ExtendedDefaultRulesvivid-synth2017-02-144-0/+71
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Expressions like the following will now typecheck: ``` data A x = A deriving Show class ToA a x where toA :: a -> A x instance ToA Integer x where toA _ = A main = print (toA 5 :: A Bool) ``` The new defaulting rules are Find all the unsolved constraints. Then: * Find those that have exactly one free type variable, and partition that subset into groups that share a common type variable `a`. * Now default `a` (to one of the types in the default list) if at least one of the classes `Ci` is an interactive class Reviewers: goldfire, bgamari, austin, mpickering, simonpj Reviewed By: bgamari, simonpj Subscribers: mpickering, simonpj, goldfire, thomie Differential Revision: https://phabricator.haskell.org/D2822
* Refactor renaming of operators/sections to fix DuplicateRecordFields bugsAdam Gundry2017-02-143-0/+16
| | | | | | | | | | | | | | | | | | A variety of panics were possible because the get_op function in RnTypes didn't handle the possibility that its argument might be an ambiguous record field. I've made its return type more informative to correctly handle occurrences of record fields. Fixes Trac #13132. Test Plan: new test overloadedrecflds/should_fail/T13132_duplicaterecflds Reviewers: bgamari, simonpj, austin Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D3126
* Typos in notes and comments [ci skip]Gabor Greif2017-02-131-1/+1
|
* Disable PVP warnings temporarily.Edward Z. Yang2017-02-124-20/+0
| | | | | | | | | While the intent is good, they are actually too aggressive: if a module reexports an identifier from a signature, we will warn (even though we should not!) We'll have to implement this differently. Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
* Slightly reword not-exported message.Edward Z. Yang2017-02-125-7/+7
| | | | Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
* Setup more error context for Backpack operations.Edward Z. Yang2017-02-1226-100/+149
| | | | | | | | | | | | Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu> Test Plan: validate Reviewers: bgamari, simonpj, austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D3101
* zonkCt tries to maintain the canonical form of a Ct.Christiaan Baaij2017-02-113-0/+43
| | | | | | | | | | | | | | | | | | | For example, - a CDictCan should stay a CDictCan; - a CTyEqCan should stay a CTyEqCan (if the LHS stays as a variable.). - a CHoleCan should stay a CHoleCan Why? For CDicteqCan see Trac #11525. Test Plan: Validate Reviewers: austin, adamgundry, simonpj, goldfire, bgamari Reviewed By: simonpj, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D3105
* Fix #13214 by correctly setting up dep_orphs for signatures.Edward Z. Yang2017-02-118-0/+143
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Prior to this, I hadn't thought about orphan handling at all. This commit implements the semantics that if a signature (transitively) imports an orphan instance, that instance is considered in scope no matter what the implementing module is. (As it turns out, this is the semantics that falls out when orphans are recorded transitively.) This patch fixes a few bugs: 1. Put semantic modules in dep_orphs rather than identity modules. 2. Don't put the implementing module in dep_orphs when merging signatures (this is a silly bug that happened because we were reusing calculateAvails, which is designed for imports. It mostly works for signature merging, except this case.) 3. When renaming a signature, blast in the orphans of the implementing module inside Dependencies. Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu> Test Plan: validate Reviewers: bgamari, austin Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D3095
* Improve the Occurrence Analyzer’s handling of one-shot functionsJoachim Breitner2017-02-111-45/+48
| | | | | | | | | | | | | | | | | | | | | When determining whether an expression is used saturatedly, count the number of value arguments that the occurrence analyser sees, and add the number of one-shot arguments that we know (from the strictness analyser) are passed from the context. perf results suggest no noticable change in allocations, reduction of code sizes, and performance regression possibliy due to loss of join points. Test Plan: perf.haskell.org Reviewers: simonpj, austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D3089
* Mark orphan instances and rules in --show-iface outputReid Barton2017-02-114-0/+40
| | | | | | | | | | | | Test Plan: new test Orphans Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D3086
* Refactor DeriveAnyClass's instance context inferenceRyan Scott2017-02-1014-49/+130
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Currently, `DeriveAnyClass` has two glaring flaws: * It only works on classes whose argument is of kind `*` or `* -> *` (#9821). * The way it infers constraints makes no sense. It basically co-opts the algorithms used to infer contexts for `Eq` (for `*`-kinded arguments) or `Functor` (for `(* -> *)`-kinded arguments). This tends to produce overly constrained instances, which in extreme cases can lead to legitimate things failing to typecheck (#12594). Or even worse, it can trigger GHC panics (#12144 and #12423). This completely reworks the way `DeriveAnyClass` infers constraints to fix these two issues. It now uses the type signatures of the derived class's methods to infer constraints (and to simplify them). A high-level description of how this works is included in the GHC users' guide, and more technical notes on what is going on can be found as comments (and a Note) in `TcDerivInfer`. Fixes #9821, #12144, #12423, #12594. Test Plan: ./validate Reviewers: dfeuer, goldfire, simonpj, austin, bgamari Subscribers: dfeuer, thomie Differential Revision: https://phabricator.haskell.org/D2961
* Relax test TH_addCStub2 so it succeeds on travis.Facundo Domínguez2017-02-102-7/+11
| | | | | | | | | | | | Test Plan: ./validate Reviewers: bgamari, nomeata, austin, mpickering Reviewed By: mpickering Subscribers: mpickering, rwbarton, mboes, thomie Differential Revision: https://phabricator.haskell.org/D3124
* Prevent Template Haskell splices from throwing a spurious TypeInType errorRyan Scott2017-02-102-0/+30
| | | | | | | | | | | | | | | | | | | | | | Summary: There was a rather annoying corner case where splicing poly-kinded Template Haskell declarations could trigger an error muttering about `TypeInType` not being enabled, whereas the equivalent non-TH code would compile without issue. This was causing by overzealous validity check in the renamer, wherein failed to distinguish between two different `Exact` names with the same `OccName`. As a result, it mistakenly believed some type variables were being used as both type and kind variables simultaneously! Ack. This avoids the issue by simply disabling the aforementioned validity check for Exact names. Fixes #12503. Test Plan: ./validate Reviewers: austin, bgamari, goldfire Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D3022
* Change rewritableTyVarsOfType to anyRewritableTyVarSimon Peyton Jones2017-02-101-3/+2
| | | | | | This fixes the regression in FrozenErrorTests, eliminates the awkward "crash on forall" in rewritableTyVars, and makes it more efficient too.
* TH-spliced class instances are pretty-printed incorrectly post-#3384Alan Zimmerman2017-02-107-33/+134
| | | | | | | | | | | | | | | | Summary: The HsSyn prettyprinter tests patch 499e43824bda967546ebf95ee33ec1f84a114a7c broke the pretty-printing of Template Haskell-spliced class instances. Test Plan: ./validate Reviewers: RyanGlScott, austin, goldfire, bgamari Reviewed By: RyanGlScott, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D3043
* Guard rewritableTyVarsOfTypeSimon Peyton Jones2017-02-091-2/+3
| | | | | | | | We only want to use rewriteableTyVarsOfType on CDictCan, CFunEqCan (and maybe CIrredCan). But not CTyEqCan. But we were -- for insolubles. So I narrowed the scope of the insuluble kick-out.
View Lorry Controller Status