summaryrefslogtreecommitdiff
path: root/testsuite/tests/indexed-types
Commit message (Collapse)AuthorAgeFilesLines
...
* Fix #15852 by eta expanding data family instance RHSes, tooRyan Scott2018-11-223-0/+24
| | | | | | | | | | | | | | | | | | | | | | When I defined `etaExpandFamInstLHS`, I blatantly forgot to eta expand the RHSes of data family instances. (Actually, I claimed that they didn't //need// to be eta expanded. I'm not sure what I was thinking.) This fixes the issue by changing `etaExpandFamInstLHS` to `etaExpandFamInst` and, well, making it actually eta expand the RHS. Test Plan: make test TEST=T15852 Reviewers: goldfire, bgamari Reviewed By: goldfire Subscribers: rwbarton, carter GHC Trac Issues: #15852 Differential Revision: https://phabricator.haskell.org/D5328
* Move eta-reduced coaxiom compatibility handling quirks into FamInstEnv.mniip2018-11-012-0/+13
| | | | | | | | | | | | | | | | | | | | The quirk caused an issue where GHC concluded that 'D' is possibly unifiable with 'D a' (the two types could have the same kind if D is a data family). Test Plan: Ensure T9371 stays fixed. Introduce T15704 Reviewers: goldfire, bgamari Reviewed By: goldfire Subscribers: RyanGlScott, rwbarton, carter GHC Trac Issues: #15704 Differential Revision: https://phabricator.haskell.org/D5206
* Test T15711 in indexed-types/should_compile/T15711Richard Eisenberg2018-10-293-0/+14
|
* Finish fix for #14880.Tobias Dammers2018-10-281-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The real change that fixes the ticket is described in Note [Naughty quantification candidates] in TcMType. Fixing this required reworking candidateQTyVarsOfType, the function that extracts free variables as candidates for quantification. One consequence is that we now must be more careful when quantifying: any skolems around must be quantified manually, and quantifyTyVars will now only quantify over metavariables. This makes good sense, as skolems are generally user-written and are listed in the AST. As a bonus, we now have more control over the ordering of such skolems. Along the way, this commit fixes #15711 and refines the fix to #14552 (by accepted a program that was previously rejected, as we can now accept that program by zapping variables to Any). This commit also does a fair amount of rejiggering kind inference of datatypes. Notably, we now can skip the generalization step in kcTyClGroup for types with CUSKs, because we get the kind right the first time. This commit also thus fixes #15743 and #15592, which both concern datatype kind generalisation. (#15591 is also very relevant.) For this aspect of the commit, see Note [Required, Specified, and Inferred in types] in TcTyClsDecls. Test cases: dependent/should_fail/T14880{,-2}, dependent/should_fail/T15743[cd] dependent/should_compile/T15743{,e} ghci/scripts/T15743b polykinds/T15592 dependent/should_fail/T15591[bc] ghci/scripts/T15591
* More explicit foralls (GHC Proposal 0007)Matthew Yacavone2018-10-2713-14/+229
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* A little more wibbling to -ddump-typesSimon Peyton Jones2018-10-251-0/+2
|
* Improve output from -ddump-typesSimon Peyton Jones2018-10-241-2/+3
| | | | | | | | | | | | | | | | | | This patch makes a number of improvements to the output generated by -ddump-types * Prints data constructor separately * Omits empty chunks of output I was driven initially by the unhelpful existing output for data constructors, but ended up doing some refactoring. Lots of error message wibbles, but nothing significant. Certainly no change in user behaviour. (NB: It is just possible that I have failed to cleanly separate this patch from the next one, about isPredTy and friends.)
* Enable -Wcompat=error in the testsuiteVladislav Zavialov2018-10-1577-128/+259
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Enabling -Werror=compat in the testsuite allows us to easily see the impact that a new warning has on code. It also means that in the period between adding the warning and making the actual breaking change, all new test cases that are being added to the testsuite will be forwards-compatible. This is good because it will make the actual breaking change contain less irrelevant testsuite updates. Things that -Wcompat warns about are things that are going to break in the future, so we can be proactive and keep our testsuite forwards-compatible. This patch consists of two main changes: * Add `TEST_HC_OPTS += -Werror=compat` to the testsuite configuration. * Fix all broken test cases. Test Plan: Validate Reviewers: hvr, goldfire, bgamari, simonpj, RyanGlScott Reviewed By: goldfire, RyanGlScott Subscribers: rwbarton, carter GHC Trac Issues: #15278 Differential Revision: https://phabricator.haskell.org/D5200
* Allow (unparenthesized) kind signaturesAlec Theriault2018-10-041-2/+2
| | | | | | | | | | | | | | | | Summary: This allows for things like `[t :: MyKind]`, `(a :: k, b)`, and so on. Test Plan: make TEST=T11622 && make TEST=T8708 Reviewers: RyanGlScott, bgamari, simonpj, goldfire, alanz Reviewed By: RyanGlScott, simonpj Subscribers: alanz, simonpj, rwbarton, mpickering, carter GHC Trac Issues: #11622, #8708 Differential Revision: https://phabricator.haskell.org/D5173
* Better -ddump-typesSimon Peyton Jones2018-10-041-6/+2
| | | | | | | | | | | The debug flag -ddump-types is supposed to show the type of Ids, and the kinds of type constructors. It was doing the former but not the latter -- instead it was using showTyTying, which is actually less helpful when debugging. This patch changes it to print the kind and roles of the thing. I also made -ddump-types show pattern synonyms
* Fix Lint of unsaturated type familiesSimon Peyton Jones2018-09-262-0/+14
| | | | | | | | | | GHC allows types to have unsaturated type synonyms and type families, provided they /are/ saturated if you expand all type synonyms. TcValidity carefully checked this; see check_syn_tc_app. But Lint only did half the job, adn that led to Trac #15664. This patch just teaches Core Lint to be as clever as TcValidity.
* Reject class instances with type families in kindsRyan Scott2018-09-023-14/+17
| | | | | | | | | | | | | | | | | | | | | Summary: GHC doesn't know how to handle type families that appear in class instances. Unfortunately, GHC didn't reject instances where type families appear in //kinds//, leading to #15515. This is easily rectified by calling `checkValidTypePat` on all arguments to a class in an instance (and not just the type arguments). Test Plan: make test TEST=T15515 Reviewers: bgamari, goldfire, simonpj Reviewed By: simonpj Subscribers: simonpj, rwbarton, carter GHC Trac Issues: #15515 Differential Revision: https://phabricator.haskell.org/D5068
* Allow scoped type variables refer to typesJoachim Breitner2018-08-054-50/+1
| | | | | | | | | | | | 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
* Refactor (~) to reduce the suerpclass stackSimon Peyton Jones2018-07-271-2/+1
| | | | | | | | | | | | | | | | | | | | | | | The constraint (~) used to be (effectively): class a ~~ b => (a :: k) ~ (b :: k) but, with this patch, it is now defined uniformly with (~~) and Coercible like this: class a ~# b => (a :: k) ~ (b :: k) Result: * One less superclass selection when goinng from (~) to (~#) Better for compile time and better for debugging with -ddump-simpl * The code for (~), (~~), and Coercible looks uniform, and appears together, e.g. in TysWiredIn and ClsInst.matchGlobalInst. Previously the code for (~) was different, and unique. Not only is this simpler, but it also makes the compiler a bit faster; T12227: 9% less allocation T12545: 7% less allocation This patch fixes Trac #15421
* Set GenSigCtxt for the argument part of tcSubTypeSimon Peyton Jones2018-07-251-2/+2
| | | | | | | | | | | The reason for this change is described in TcUnify Note [Settting the argument context], and Trac #15438. The only effect is on error messages, where it stops GHC reporting an outright falsity (about the type signature for a function) when it finds an errors in a higher-rank situation. The testsuite changes in this patch illustrate the problem.
* Fix #15423 by using pprAStmtContextRyan Scott2018-07-201-1/+1
| | | | | | | | | | | | | | | | | Summary: Previously, we were using `pprStmtContext` instead, which led to error messages missing indefinite articles where they were required. Test Plan: make test TEST="T13242a T7786 Typeable1" Reviewers: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #15423 Differential Revision: https://phabricator.haskell.org/D4992
* Use IfaceAppArgs to store an IfaceAppTy's argumentsRyan Scott2018-07-111-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Currently, an `IfaceAppTy` has no way to tell whether its argument is visible or not, so it simply treats all arguments as visible, leading to #15330. We already have a solution for this problem in the form of the `IfaceTcArgs` data structure, used by `IfaceTyConApp` to represent the arguments to a type constructor. Therefore, it makes sense to reuse this machinery for `IfaceAppTy`, so this patch does just that. This patch: 1. Renames `IfaceTcArgs` to `IfaceAppArgs` to reflect its more general purpose. 2. Changes the second field of `IfaceAppTy` from `IfaceType` to `IfaceAppArgs`, and propagates the necessary changes through. In particular, pretty-printing an `IfaceAppTy` now goes through the `IfaceAppArgs` pretty-printer, which correctly displays arguments as visible or not for free, fixing #15330. 3. Changes `toIfaceTypeX` and related functions so that when converting an `AppTy` to an `IfaceAppTy`, it flattens as many argument `AppTy`s as possible, and then converts those arguments into an `IfaceAppArgs` list, using the kind of the function `Type` as a guide. (Doing so minimizes the number of times we need to call `typeKind`, which is more expensive that finding the kind of a `TyCon`.) Test Plan: make test TEST=T15330 Reviewers: goldfire, simonpj, bgamari Reviewed By: simonpj Subscribers: rwbarton, thomie, carter GHC Trac Issues: #15330 Differential Revision: https://phabricator.haskell.org/D4938
* Add test for Trac #15352Simon Peyton Jones2018-07-112-0/+33
|
* Kind-check CUSK associated types separatelyRichard Eisenberg2018-07-102-0/+15
| | | | | | | | | | | | Previously, we kind-checked associated types while while still figuring out the kind of a CUSK class. This caused trouble, as documented in Note [Don't process associated types in kcLHsQTyVars] in TcTyClsDecls. This commit moves this process after the initial kind of the class is determined. Fixes #15142. Test case: indexed-types/should_compile/T15142.hs
* Make ppr_tc_args aware of -fprint-explicit-kindsRyan Scott2018-07-051-1/+1
| | | | | | | | | | | | | | | | | | Summary: `ppr_tc_args` was printing invisible kind arguments even when `-fprint-explicit-kinds` wasn't enabled. Easily fixed. Test Plan: make test TEST=T15341 Reviewers: goldfire, bgamari, simonpj Reviewed By: simonpj Subscribers: simonpj, rwbarton, thomie, carter GHC Trac Issues: #15341 Differential Revision: https://phabricator.haskell.org/D4932
* Fix newtype instance GADTsRyan Scott2018-07-052-0/+9
| | | | | | | | | | | | | | | | | | | | | Summary: This was taken from Richard's branch, which in turn was submitted to Phab by Matthew, which in turn was commandeered by Ryan. This fixes an issue with newtype instances in which too many coercions were being applied in the worker. This fixes the issue by removing the data family instance axiom from the worker and moving to the wrapper. Moreover, we now require all newtype instances to have wrappers, for symmetry with data instances. Reviewers: goldfire, bgamari, simonpj, mpickering Reviewed By: mpickering Subscribers: simonpj, rwbarton, thomie, carter GHC Trac Issues: #15318 Differential Revision: https://phabricator.haskell.org/D4902
* Refactor validity checking for constraintsSimon Peyton Jones2018-07-055-0/+46
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There are several changes here. * TcInteract has gotten too big, so I moved all the class-instance matching out of TcInteract into a new module ClsInst. It parallels the FamInst module. The main export of ClsInst is matchGlobalInst. This now works in TcM not TcS. * A big reason to make matchGlobalInst work in TcM is that we can then use it from TcValidity.checkSimplifiableClassConstraint. That extends checkSimplifiableClassConstraint to work uniformly for built-in instances, which means that we now get a warning if we have givens (Typeable x, KnownNat n); see Trac #15322. * This change also made me refactor LookupInstResult, in particular by adding the InstanceWhat field. I also changed the name of the type to ClsInstResult. Then instead of matchGlobalInst reporting a staging error (which is inappropriate for the call from TcValidity), we can do so in TcInteract.checkInstanceOK. * In TcValidity, we now check quantified constraints for termination. For example, this signature should be rejected: f :: (forall a. Eq (m a) => Eq (m a)) => blah as discussed in Trac #15316. The main change here is that TcValidity.check_pred_help now uses classifyPredType, and has a case for ForAllPred which it didn't before. This had knock-on refactoring effects in TcValidity.
* Fix typechecking of kind signaturesSimon Peyton Jones2018-06-183-0/+15
| | | | | | | | | | | | | | | 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
* Fix an infinite loop in niFixTCvSubstSimon Peyton Jones2018-06-182-0/+11
| | | | | | | | | | | | | | | | | | | | | Trac #14164 made GHC loop, a pretty serious error. It turned out that Unify.niFixTCvSubst was looping forever, because we had a substitution like a :-> ....(b :: (c :: d)).... d :-> ... We correctly recognised that d was free in the range of the substitution, but then failed to apply it "deeeply enough" to the range of the substiuttion, so d was /still/ free in the range, and we kept on going. Trac #9106 was caused by a similar problem, but alas my fix to Trac #9106 was inadequate when the offending type variable is more deeply buried. Urk. This time I think I've fixed it! It's much more subtle than I though, and it took most of a long train journey to figure it out. I wrote a long note to explain: Note [Finding the substitution fixpoint]
* Quantify unfixed kind variables in CUSKsRichard Eisenberg2018-06-154-21/+3
| | | | | | | | | | | | 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
* Built-in Natural literals in CoreSylvain Henry2018-06-151-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add support for built-in Natural literals in Core. - Replace MachInt,MachWord, LitInteger, etc. with a single LitNumber constructor with a LitNumType field - Support built-in Natural literals - Add desugar warning for negative literals - Move Maybe(..) from GHC.Base to GHC.Maybe for module dependency reasons This patch introduces only a few rules for Natural literals (compared to Integer's rules). Factorization of the built-in rules for numeric literals will be done in another patch as this one is already big to review. Test Plan: validate test build with integer-simple Reviewers: hvr, bgamari, goldfire, Bodigrim, simonmar Reviewed By: bgamari Subscribers: phadej, simonpj, RyanGlScott, carter, hsyl20, rwbarton, thomie GHC Trac Issues: #14170, #14465 Differential Revision: https://phabricator.haskell.org/D4212
* Add "quantified constraint" context in error message, fix #15231.HE, Tao2018-06-153-5/+6
| | | | | | | | | | | | | | | | | | | | This patch adds "quantified constraint" context in error message when UndecidableInstances checking fails for quantified constraints. See Trac #15231:comment#1. This patch also pretty-prints the instance head for better error messages. Test Plan: make test TEST="T15231" Reviewers: bgamari, simonpj Reviewed By: simonpj Subscribers: simonpj, rwbarton, thomie, carter GHC Trac Issues: #15231 Differential Revision: https://phabricator.haskell.org/D4819
* Embrace -XTypeInType, add -XStarIsTypeVladislav Zavialov2018-06-1439-107/+130
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Implement the "Embrace Type :: Type" GHC proposal, .../ghc-proposals/blob/master/proposals/0020-no-type-in-type.rst GHC 8.0 included a major change to GHC's type system: the Type :: Type axiom. Though casual users were protected from this by hiding its features behind the -XTypeInType extension, all programs written in GHC 8+ have the axiom behind the scenes. In order to preserve backward compatibility, various legacy features were left unchanged. For example, with -XDataKinds but not -XTypeInType, GADTs could not be used in types. Now these restrictions are lifted and -XTypeInType becomes a redundant flag that will be eventually deprecated. * Incorporate the features currently in -XTypeInType into the -XPolyKinds and -XDataKinds extensions. * Introduce a new extension -XStarIsType to control how to parse * in code and whether to print it in error messages. Test Plan: Validate Reviewers: goldfire, hvr, bgamari, alanz, simonpj Reviewed By: goldfire, simonpj Subscribers: rwbarton, thomie, mpickering, carter GHC Trac Issues: #15195 Differential Revision: https://phabricator.haskell.org/D4748
* Fix #13777 by improving the underdetermined CUSK error messageRyan Scott2018-06-023-0/+35
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-263-0/+48
|
* Clean up the conflicting data family instances error messageRyan Scott2018-05-2413-42/+76
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Use dischargeFunEq consistentlySimon Peyton Jones2018-05-232-0/+17
| | | | | | | | | | | | | | | | | | | | | | | | Trac #15122 turned out to be interesting. * Were calling dischargeFmv in three places. * In all three cases we dealt with the Given case separately. * In two of the three cases the Given code was right, (albeit duplicated). * In the third case (in TcCanonical.canCFunEqCan), we had ; case flav of Given -> return () -- nothing more to do. which was utterly wrong. The solution is easy: move the Given-case handling into dischargeFmv (now reenamed dischargeFunEq), and delete it from the call sites. Result: less code, easier to understand (dischargeFunEq handles all three cases, not just two out of three), and Trac #15122 is fixed.
* Check for type families in an instance contextSimon Peyton Jones2018-05-213-0/+17
| | | | | | This patch adds a check for type families to the instance-decl termination check. See Note [Type families in instance contexts] and Trac #15172.
* ghc-prim: Bump versionBen Gamari2018-05-201-1/+1
| | | | | | | | | | | | | unpackClosure#'s behavior and type has changed. This caused a CPP guard in the new ghc-heap package to fail when bootstrapping with GHC 8.4. Test Plan: Validate bootstrapping with GHC 8.4 Reviewers: RyanGlScott Subscribers: rwbarton, thomie, carter Differential Revision: https://phabricator.haskell.org/D4716
* Do not unify representational equalitiesSimon Peyton Jones2018-05-182-0/+19
| | | | | | | | | | This patch is an easy fix to Trac #15144, which was caused by accidentally unifying a representational equality in the unflattener. (The main code in TcInteract was always careful not to do so, but I'd missed the test in the unflattener.) See Note [Do not unify representational equalities] in TcInteract
* Orient TyVar/TyVar equalities with deepest on the leftSimon Peyton Jones2018-05-182-23/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Trac #15009 showed that, for Given TyVar/TyVar equalities, we really want to orient them with the deepest-bound skolem on the left. As it happens, we also want to do the same for Wanteds, but for a different reason (more likely to be touchable). Either way, deepest wins: see TcUnify Note [Deeper level on the left]. This observation led me to some significant changes: * A SkolemTv already had a TcLevel, but the level wasn't really being used. Now it is! * I updated added invariant (SkolInf) to TcType Note [TcLevel and untouchable type variables], documenting that the level number of all the ic_skols should be the same as the ic_tclvl of the implication * FlatSkolTvs and FlatMetaTvs previously had a dummy level-number of zero, which messed the scheme up. Now they get a level number the same way as all other TcTyVars, instead of being a special case. * To make sure that FlatSkolTvs and FlatMetaTvs are untouchable (which was previously done via their magic zero level) isTouchableMetaTyVar just tests for those two cases. * TcUnify.swapOverTyVars is the crucial orientation function; see the new Note [TyVar/TyVar orientation]. I completely rewrote this function, and it's now much much easier to understand. I ended up doing some related refactoring, of course * I noticed that tcImplicitTKBndrsX and tcExplicitTKBndrsX were doing a lot of useless work in the case where there are no skolems; I added a fast-patch * Elminate the un-used tcExplicitTKBndrsSig; and thereby get rid of the higher-order parameter to tcExpliciTKBndrsX. * Replace TcHsType.emitTvImplication with TcUnify.checkTvConstraints, by analogy with TcUnify.checkConstraints. * Inline TcUnify.buildImplication into its only call-site in TcUnify.checkConstraints * TcS.buildImplication becomes TcS.CheckConstraintsTcS, with a simpler API * Now that we have NoEvBindsVar we have no need of termEvidenceAllowed; nuke the latter, adding Note [No evidence bindings] to TcEvidence.
* Fix another batch of `./validate --slow` failuresAlp Mestanogullari2018-05-131-1/+7
| | | | | | | | | | | | | | | | | | | | | | A rather detailed summary can be found at: https://gist.github.com/alpmestan/be82b47bb88b7dc9ff84105af9b1bb82 This doesn't fix all expectation mismatches yet, but we're down to about 20 mismatches with my previous patch and this one, as opposed to ~150 when I got started. Test Plan: ./validate --slow Reviewers: bgamari, erikd, simonmar Reviewed By: simonmar Subscribers: thomie, carter GHC Trac Issues: #14890 Differential Revision: https://phabricator.haskell.org/D4636
* Add 'addWordC#' PrimOpSebastian Graf2018-05-051-1/+1
| | | | | | | | | | | | | | | | | | | This is mostly for congruence with 'subWordC#' and '{add,sub}IntC#'. I found 'plusWord2#' while implementing this, which both lacks documentation and has a slightly different specification than 'addWordC#', which means the generic implementation is unnecessarily complex. While I was at it, I also added lacking meta-information on PrimOps and refactored 'subWordC#'s generic implementation to be branchless. Reviewers: bgamari, simonmar, jrtc27, dfeuer Reviewed By: bgamari, dfeuer Subscribers: dfeuer, thomie, carter Differential Revision: https://phabricator.haskell.org/D4592
* Do not unpack class dictionaries with INLINABLESimon Peyton Jones2018-04-261-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Matthew Pickering uncovered a bad performance hole in the way that single-method dictionaries work, described in Trac #14955. See Note [Do not unpack class dictionaries] in WwLib. I tried to fix this 6 years ago, but got it slightly wrong. This patch fixes it, which makes a dramatic improvement in the test case. Nofib highlights: not much happening: Program Size Allocs Runtime Elapsed TotalMem ----------------------------------------------------------------- VSM -0.3% +2.7% -7.4% -7.4% 0.0% cacheprof -0.0% +0.1% +0.3% +0.7% 0.0% integer -0.0% +1.1% +7.5% +7.5% 0.0% tak -0.1% -0.2% 0.024 0.024 0.0% ----------------------------------------------------------------- Min -4.4% -0.2% -7.4% -7.4% -8.0% Max +0.6% +2.7% +7.5% +7.5% 0.0% Geom Mean -0.1% +0.0% +0.1% +0.1% -0.2% I investigated VSM. The patch unpacks class dictionaries a bit more than before (i.e. does so if there is no INLINABLE pragma). And that gives better code in VSM (less dictionary selection etc), but one closure gets one word bigger. I'll accept these changes in exchange for more robust performance. Some ghci.debugger output wobbled around (order of bindings being displayed). I have no idea why; but I accepted the changes.
* Lint types in newFamInstRyan Scott2018-04-192-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We weren't linting the types used in `newFamInst`, which might have been why #15012 went undiscovered for so long. Let's fix that. One has to be surprisingly careful with expanding type synonyms in `lintType`, since in the offending program (simplified): ```lang=haskell type FakeOut a = Int type family TF a type instance TF Int = FakeOut a ``` If one expands type synonyms, then `FakeOut a` will expand to `Int`, which masks the issue (that `a` is unbound). I added an extra Lint flag to configure whether type synonyms should be expanded or not in Lint, and disabled this when calling `lintTypes` from `newFamInst`. As evidence that this works, I ran it on the offending program from #15012, and voilà: ``` $ ghc3/inplace/bin/ghc-stage2 Bug.hs -dcore-lint [1 of 1] Compiling Foo ( Bug.hs, Bug.o ) ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.5.20180417 for x86_64-unknown-linux): Core Lint error <no location info>: warning: In the type ‘... (Rec0 (FakeOut b_a1Qt))))’ @ b_a1Qt is out of scope ``` Test Plan: make test TEST=T15057 Reviewers: simonpj, goldfire, bgamari Reviewed By: bgamari Subscribers: thomie, carter GHC Trac Issues: #15057 Differential Revision: https://phabricator.haskell.org/D4611
* Bump base to version 4.12.0.0Ryan Scott2018-04-191-1/+1
| | | | | | | | | | | | | | | | Summary: Bumps several submodules. Test Plan: ./validate Reviewers: hvr, bgamari Reviewed By: bgamari Subscribers: thomie, carter GHC Trac Issues: #15018 Differential Revision: https://phabricator.haskell.org/D4609
* Bump version numbers: base-4.11.1.0, integer-gmp-1.0.2.0Ryan Scott2018-04-131-2/+2
| | | | | | | | | | | | | | | | | | | | | This takes care of bumping the `base` and `integer-gmp` minor version numbers in anticipation of a GHC 8.4.2 release. While I was in town, I also filled in a `@since TODO` Haddock annotation for `powModSecInteger` in `integer-gmp` with `1.0.2.0`, and updated the changelog accordingly. Test Plan: ./validate Reviewers: hvr, goldfire, bgamari Reviewed By: bgamari Subscribers: thomie, carter GHC Trac Issues: #15025 Differential Revision: https://phabricator.haskell.org/D4586
* Track type variable scope more carefully.Richard Eisenberg2018-03-312-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The main job of this commit is to track more accurately the scope of tyvars introduced by user-written foralls. For example, it would be to have something like this: forall a. Int -> (forall k (b :: k). Proxy '[a, b]) -> Bool In that type, a's kind must be k, but k isn't in scope. We had a terrible way of doing this before (not worth repeating or describing here, but see the old tcImplicitTKBndrs and friends), but now we have a principled approach: make an Implication when kind-checking a forall. Doing so then hooks into the existing machinery for preventing skolem-escape, performing floating, etc. This also means that we bump the TcLevel whenever going into a forall. The new behavior is done in TcHsType.scopeTyVars, but see also TcHsType.tc{Im,Ex}plicitTKBndrs, which have undergone significant rewriting. There are several Notes near there to guide you. Of particular interest there is that Implication constraints can now have skolems that are out of order; this situation is reported in TcErrors. A major consequence of this is a slightly tweaked process for type- checking type declarations. The new Note [Use SigTvs in kind-checking pass] in TcTyClsDecls lays it out. The error message for dependent/should_fail/TypeSkolEscape has become noticeably worse. However, this is because the code in TcErrors goes to some length to preserve pre-8.0 error messages for kind errors. It's time to rip off that plaster and get rid of much of the kind-error-specific error messages. I tried this, and doing so led to a lovely error message for TypeSkolEscape. So: I'm accepting the error message quality regression for now, but will open up a new ticket to fix it, along with a larger error-message improvement I've been pondering. This applies also to dependent/should_fail/{BadTelescope2,T14066,T14066e}, polykinds/T11142. Other minor changes: - isUnliftedTypeKind didn't look for tuples and sums. It does now. - check_type used check_arg_type on both sides of an AppTy. But the left side of an AppTy isn't an arg, and this was causing a bad error message. I've changed it to use check_type on the left-hand side. - Some refactoring around when we print (TYPE blah) in error messages. The changes decrease the times when we do so, to good effect. Of course, this is still all controlled by -fprint-explicit-runtime-reps Fixes #14066 #14749 Test cases: dependent/should_compile/{T14066a,T14749}, dependent/should_fail/T14066{,c,d,e,f,g,h}
* Don't apply dataToTag's caseRules for data familiesRyan Scott2018-02-032-0/+20
| | | | | | | | | | | | | | | | | | | | | Commit 193664d42dbceadaa1e4689dfa17ff1cf5a405a0 added a special caseRule for `dataToTag`, but this transformation completely broke when `dataToTag` was applied to somewith with a type headed by a data family, leading to #14680. For now at least, the simplest solution is to simply not apply this transformation when the type is headed by a data family. Test Plan: make test TEST=T14680 Reviewers: simonpj, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #14680 Differential Revision: https://phabricator.haskell.org/D4371
* Turn EvTerm (almost) into CoreExpr (#14691)Joachim Breitner2018-01-261-1/+1
| | | | | | | | | | | | | | | | | Ideally, I'd like to do type EvTerm = CoreExpr and the type checker builds the evidence terms as it goes. This failed, becuase the evidence for `Typeable` refers to local identifiers that are added *after* the typechecker solves constraints. Therefore, `EvTerm` stays a data type with two constructors: `EvExpr` for `CoreExpr` evidence, and `EvTypeable` for the others. Delted `Note [Memoising typeOf]`, its reference (and presumably relevance) was removed in 8fa4bf9. Differential Revision: https://phabricator.haskell.org/D4341
* Drop dead Given bindings in setImplicationStatusSimon Peyton Jones2018-01-041-1/+0
| | | | | | | | | | | | | | | | | | Trac #13032 pointed out that we sometimes generate unused bindings for Givens, and (worse still) we can't always discard them later (we don't drop a case binding unless we can prove that the scrutinee is non-bottom. It looks as if this may be a major reason for the performace problems in #14338 (see comment:29). This patch fixes the problem at source, by pruning away all the dead Givens. See Note [Delete dead Given evidence bindings] Remarkably, compiler allocation falls by 23% in perf/compiler/T12227! I have not confirmed whether this change actualy helps with
* Rename HEq_sc and Coercible_sc to heq_sel and coercible_selMatthew Pickering2018-01-021-2/+2
| | | | | | | | | | | | | | | | | These functions are record selectors. To the unfamiliar, when inspecting core, they looked like data constructors as they started with an upper case letter. We rename them so that it is more clear that firstly they are functions and secondly that they are selectors. Reviewers: bgamari, simonpj Reviewed By: simonpj Subscribers: simonpj, rwbarton, thomie, carter Differential Revision: https://phabricator.haskell.org/D4280
* Fix floating of equalitiesSimon Peyton Jones2017-12-211-4/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | This rather subtle patch fixes Trac #14584. The problem was that we'd allowed a coercion, bound in a nested scope, to escape into an outer scope. The main changes are * TcSimplify.floatEqualities takes more care when floating equalities to make sure we don't float one out that mentions a locally-bound coercion. See Note [What prevents a constraint from floating] * TcSimplify.emitResidualConstraints (which emits the residual constraints in simplifyInfer) now avoids burying the constraints for escaping CoVars inside the implication constraint. * Since I had do to this stuff with CoVars, I moved the fancy footwork about not quantifying over CoVars from TcMType.quantifyTyVars to its caller TcSimplify.decideQuantifiedTyVars. I think its other callers don't need to worry about all this CoVar stuff. This turned out to be surprisigly tricky, and took me a solid day to get right. I think the result is reasonably neat, though, and well documented with Notes.
* Get rid of some stuttering in comments and docsGabor Greif2017-12-191-1/+1
|
* Fix an outright bug in the unflattenerSimon Peyton Jones2017-12-142-0/+35
| | | | | | | | | Trac #14554 showed up an outright bug in the unflattening code in TcFlatten. I was filling in a coercion with the wrong coercion (a Syn in the wrong place). Result: "Bad coercion hole" assertion failures, and Core Lint Errors. Easily fixed, and the code is simpler too.
View Lorry Controller Status