summaryrefslogtreecommitdiff
path: root/testsuite/tests/polykinds
Commit message (Collapse)AuthorAgeFilesLines
* Fix a bug in occurs checkingSimon Peyton Jones2016-09-303-0/+46
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 1. Trac #12593 exposed a long-standing bug in the occurs checking machinery. When unifying two type variables a ~ b where a /= b, we were assuming that there could be no occurs-check error. But there can: 'a' can occur in b's kind! When the RHS was a non-tyvar we used occurCheckExpand, which /did/ look in kinds, but not when the RHS was a tyvar. This bug has been lurking ever since TypeInType, maybe longer. And it was present both in TcUnify (the on-the-fly unifier), and in TcInteract. I ended up refactoring both so that the tyvar/tyvar path naturally goes through the same occurs-check as non-tyvar rhss. It's simpler and more robust now. One good thing is that both unifiers now share TcType.swapOverVars TcType.canSolveByUnification previously they had different logic for the same goals 2. Fixing this bug exposed another! In T11635 we end up unifying (alpha :: forall k. k->*) ~ (beta :: forall k. k->*) Now that the occurs check is done for tyvars too, we look inside beta's kind. And then reject the program becuase of the forall inside there. But in fact that forall is fine -- it does not count as impredicative polymoprhism. See Note [Checking for foralls] in TcType. 3. All this fuss around occurrence checking forced me to look at TcUnify.checkTauTvUpdate and TcType.occurCheckExpand There's a lot of duplication there, and I managed to elminate quite a bit of it. For example, checkTauTvUpdate called a local 'defer_me'; and then called occurCheckExpand, which then used a very similar 'fast_check'. Things are better, but there is more to do.
* Trac #11554 fix loopy GADTsAlexander Vieth2016-06-303-0/+18
| | | | | | | | | | | | | | Summary: Fixes T11554 Reviewers: goldfire, thomie, simonpj, austin, bgamari Reviewed By: thomie, simonpj, bgamari Subscribers: simonpj, goldfire, thomie Differential Revision: https://phabricator.haskell.org/D2283 GHC Trac Issues: #11554
* Testsuite: tabs -> spaces [skip ci]Thomas Miedema2016-06-201-4/+4
|
* Testsuite: remove Windows CR [skip ci]Thomas Miedema2016-06-203-42/+42
|
* Major patch to introduce TyConBinderSimon Peyton Jones2016-06-153-28/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Before this patch, following the TypeInType innovations, each TyCon had two lists: - tyConBinders :: [TyBinder] - tyConTyVars :: [TyVar] They were in 1-1 correspondence and contained overlapping information. More broadly, there were many places where we had to pass around this pair of lists, instead of a single list. This commit tidies all that up, by having just one list of binders in a TyCon: - tyConBinders :: [TyConBinder] The new data types look like this: Var.hs: data TyVarBndr tyvar vis = TvBndr tyvar vis data VisibilityFlag = Visible | Specified | Invisible type TyVarBinder = TyVarBndr TyVar VisibilityFlag TyCon.hs: type TyConBinder = TyVarBndr TyVar TyConBndrVis data TyConBndrVis = NamedTCB VisibilityFlag | AnonTCB TyCoRep.hs: data TyBinder = Named TyVarBinder | Anon Type Note that Var.TyVarBdr has moved from TyCoRep and has been made polymorphic in the tyvar and visiblity fields: type TyVarBinder = TyVarBndr TyVar VisibilityFlag -- Used in ForAllTy type TyConBinder = TyVarBndr TyVar TyConBndrVis -- Used in TyCon type IfaceForAllBndr = TyVarBndr IfaceTvBndr VisibilityFlag type IfaceTyConBinder = TyVarBndr IfaceTvBndr TyConBndrVis -- Ditto, in interface files There are a zillion knock-on changes, but everything arises from these types. It was a bit fiddly to get the module loops to work out right! Some smaller points ~~~~~~~~~~~~~~~~~~~ * Nice new functions TysPrim.mkTemplateKiTyVars TysPrim.mkTemplateTyConBinders which help you make the tyvar binders for dependently-typed TyCons. See comments with their definition. * The change showed up a bug in TcGenGenerics.tc_mkRepTy, where the code was making an assumption about the order of the kind variables in the kind of GHC.Generics.(:.:). I fixed this; see TcGenGenerics.mkComp.
* Re-add FunTy (big patch)Simon Peyton Jones2016-06-151-13/+14
| | | | | | | | | | | | | | | | | | | | | | With TypeInType Richard combined ForAllTy and FunTy, but that was often awkward, and yielded little benefit becuase in practice the two were always treated separately. This patch re-introduces FunTy. Specfically * New type data TyVarBinder = TvBndr TyVar VisibilityFlag This /always/ has a TyVar it. In many places that's just what what we want, so there are /lots/ of TyBinder -> TyVarBinder changes * TyBinder still exists: data TyBinder = Named TyVarBinder | Anon Type * data Type = ForAllTy TyVarBinder Type | FunTy Type Type | .... There are a LOT of knock-on changes, but they are all routine. The Haddock submodule needs to be updated too
* A second test for Trac #12055Simon Peyton Jones2016-06-133-0/+53
| | | | | This one omits the extension, thereby making GHC 8.0 produce "GHC internal error".
* Test Trac #12055Simon Peyton Jones2016-06-132-0/+46
|
* Improve typechecking of let-bindingsSimon Peyton Jones2016-06-136-75/+80
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This major commit was initially triggered by #11339, but it spiraled into a major review of the way in which type signatures for bindings are handled, especially partial type signatures. On the way I fixed a number of other bugs, namely #12069 #12033 #11700 #11339 #11670 The main change is that I completely reorganised the way in which type signatures in bindings are handled. The new story is in TcSigs Note [Overview of type signatures]. Some specific: * Changes in the data types for signatures in TcRnTypes: TcIdSigInfo and new TcIdSigInst * New module TcSigs deals with typechecking type signatures and pragmas. It contains code mostly moved from TcBinds, which is already too big * HsTypes: I swapped the nesting of HsWildCardBndrs and HsImplicitBndsrs, so that the wildcards are on the oustide not the insidde in a LHsSigWcType. This is just a matter of convenient, nothing deep. There are a host of other changes as knock-on effects, and it all took FAR longer than I anticipated :-). But it is a significant improvement, I think. Lots of error messages changed slightly, some just variants but some modest improvements. New tests * typecheck/should_compile * SigTyVars: a scoped-tyvar test * ExPat, ExPatFail: existential pattern bindings * T12069 * T11700 * T11339 * partial-sigs/should_compile * T12033 * T11339a * T11670 One thing to check: * Small change to output from ghc-api/landmines. Need to check with Alan Zimmerman
* Make inert_model and inert_eqs deterministic setsBartosz Nitka2016-05-181-2/+2
| | | | | | | | | | | | | | | | | | | | 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
* Test Trac #11640Simon Peyton Jones2016-05-102-0/+8
|
* Remove the incredibly hairy splitTelescopeTvs.Richard Eisenberg2016-04-292-0/+32
| | | | | | | | | This patch removes splitTelescopeTvs by adding information about scoped type variables to TcTyCon. Vast simplification! This also fixes #11821 by bringing only unzonked vars into scope. Test case: polykinds/T11821
* Minor improvement to error messageSimon Peyton Jones2016-04-281-1/+1
| | | | | "One fewer arguments to ..." rather than "One fewer argument to ..."
* Kill varSetElemsWellScoped in quantifyTyVarsBartosz Nitka2016-04-262-9/+9
| | | | | | | | | | | | | | | | | | | | | | | | varSetElemsWellScoped introduces unnecessary non-determinism in inferred type signatures. Removing this instance required changing the representation of TcDepVars to use deterministic sets. This is the last occurence of varSetElemsWellScoped, allowing me to finally remove it. Test Plan: ./validate I will update the expected outputs when commiting, some reordering of type variables in types is expected. Reviewers: goldfire, simonpj, austin, bgamari Reviewed By: simonpj Subscribers: thomie, simonmar Differential Revision: https://phabricator.haskell.org/D2135 GHC Trac Issues: #4012
* Warn about simplifiable class constraintsSimon Peyton Jones2016-04-221-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Provoked by Trac #11948, this patch adds a new warning to GHC -Wsimplifiable-class-constraints It warns if you write a class constraint in a type signature that can be simplified by an existing instance declaration. Almost always this means you should simplify it right now; type inference is very fragile without it, as #11948 shows. I've put the warning as on-by-default, but I suppose that if there are howls of protest we can move it out (as happened for -Wredundant-constraints. It actually found an example of an over-complicated context in CmmNode. Quite a few tests use these weird contexts to trigger something else, so I had to suppress the warning in those. The 'haskeline' library has a few occurrences of the warning (which I think should be fixed), so I switched it off for that library in warnings.mk. The warning itself is done in TcValidity.check_class_pred. HOWEVER, when type inference fails we get a type error; and the error suppresses the (informative) warning. So as things stand, the warning only happens when it doesn't cause a problem. Not sure what to do about this, but this patch takes us forward, I think.
* SCC analysis for instances as well as types/classesSimon Peyton Jones2016-04-201-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This big patch is in pursuit of Trac #11348. It is largely the work of Alex Veith (thank you!), with some follow-up simplification and refactoring from Simon PJ. The main payload is described in RnSource Note [Dependency analysis of type, class, and instance decls] which is pretty detailed. * There is a new data type HsDecls.TyClGroup, for a strongly connected component of type/class/instance/role decls. The hs_instds field of HsGroup disappears, in consequence This forces some knock-on changes, including a minor haddock submodule update Smaller, weakly-related things * I found that both the renamer and typechecker were building an identical env for RoleAnnots, so I put common code for RoleAnnotEnv in RnEnv. * I found that tcInstDecls1 had very clumsy error handling, so I put it together into TcInstDcls.doClsInstErrorChecks
* Tighten checking for associated type instancesSimon Peyton Jones2016-04-191-7/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Make equality print better. (#11712)Richard Eisenberg2016-03-213-7/+6
|
* Clean up some pretty-printing in errors.Richard Eisenberg2016-03-151-0/+1
| | | | | | | | | | | | | It turns out that there were some pretty egregious mistakes in the code that suggested -fprint-explicit-kinds, which are fixed. This commit also reorders a bunch of error messages, which I think is an improvement. This also adds the test case for #11471, which is what triggered the cleanup in TcErrors. Now that #11473 is done, there is nothing more outstanding for #11471. test case: dependent/should_fail/T11471
* Fix printing of "kind" vs. "type"Richard Eisenberg2016-03-153-0/+16
| | | | | | | This is as reported in #11471, though it's not the focus of that ticket. test case: polykinds/KindVType
* Testsuite wibbles from previous commits.Richard Eisenberg2016-03-141-1/+1
|
* Fix #11648.Richard Eisenberg2016-03-145-1/+31
| | | | | | | | | | | | We now check that a CUSK is really a CUSK and issue an error if it isn't. This also involves more solving and zonking in kcHsTyVarBndrs, which was the outright bug reported in #11648. Test cases: polykinds/T11648{,b} This updates the haddock submodule. [skip ci]
* Test Trac #11611Simon Peyton Jones2016-02-263-0/+15
|
* 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
View Lorry Controller Status