1. 21 Mar, 2019 1 commit
    • Ryan Scott's avatar
      Reject nested predicates in impredicativity checking · 8d18a873
      Ryan Scott authored
      When GHC attempts to unify a metavariable with a type containing
      foralls, it will be rejected as an occurrence of impredicativity.
      GHC was /not/ extending the same treatment to predicate types, such
      as in the following (erroneous) example from #11514:
      foo :: forall a. (Show a => a -> a) -> ()
      foo = undefined
      This will attempt to instantiate `undefined` at
      `(Show a => a -> a) -> ()`, which is impredicative. This patch
      catches impredicativity arising from predicates in this fashion.
      Since GHC is pickier about impredicative instantiations, some test
      cases needed to be updated to be updated so as not to fall afoul of
      the new validity check. (There were a surprising number of
      impredicative uses of `undefined`!) Moreover, the `T14828` test case
      now has slightly less informative types shown with `:print`. This is
      due to a a much deeper issue with the GHCi debugger (see #14828).
      Fixes #11514.
  2. 20 Mar, 2019 1 commit
  3. 15 Mar, 2019 1 commit
  4. 12 Mar, 2019 1 commit
    • Simon Peyton Jones's avatar
      Use transSuperClasses in TcErrors · 50249a9f
      Simon Peyton Jones authored
      Code in TcErrors was recursively using immSuperClasses,
      which loops in the presence of UndecidableSuperClasses.
      Better to use transSuperClasses instead, which has a loop-breaker
      mechanism built in.
      Fixes issue #16414.
  5. 24 Feb, 2019 1 commit
    • Simon Peyton Jones's avatar
      Add AnonArgFlag to FunTy · 6cce36f8
      Simon Peyton Jones authored
      The big payload of this patch is:
        Add an AnonArgFlag to the FunTy constructor
        of Type, so that
          (FunTy VisArg   t1 t2) means (t1 -> t2)
          (FunTy InvisArg t1 t2) means (t1 => t2)
      The big payoff is that we have a simple, local test to make
      when decomposing a type, leading to many fewer calls to
      isPredTy. To me the code seems a lot tidier, and probably
      more efficient (isPredTy has to take the kind of the type).
      See Note [Function types] in TyCoRep.
      There are lots of consequences
      * I made FunTy into a record, so that it'll be easier
        when we add a linearity field, something that is coming
        down the road.
      * Lots of code gets touched in a routine way, simply because it
        pattern matches on FunTy.
      * I wanted to make a pattern synonym for (FunTy2 arg res), which
        picks out just the argument and result type from the record. But
        alas the pattern-match overlap checker has a heart attack, and
        either reports false positives, or takes too long.  In the end
        I gave up on pattern synonyms.
        There's some commented-out code in TyCoRep that shows what I
        wanted to do.
      * Much more clarity about predicate types, constraint types
        and (in particular) equality constraints in kinds.  See TyCoRep
        Note [Types for coercions, predicates, and evidence]
        and Note [Constraints in kinds].
        This made me realise that we need an AnonArgFlag on
        AnonTCB in a TyConBinder, something that was really plain
        wrong before. See TyCon Note [AnonTCB InivsArg]
      * When building function types we must know whether we
        need VisArg (mkVisFunTy) or InvisArg (mkInvisFunTy).
        This turned out to be pretty easy in practice.
      * Pretty-printing of types, esp in IfaceType, gets
        tidier, because we were already recording the (->)
        vs (=>) distinction in an ad-hoc way.  Death to
      * mkLamType needs to keep track of whether it is building
        (t1 -> t2) or (t1 => t2).  See Type
        Note [mkLamType: dictionary arguments]
      Other minor stuff
      * Some tidy-up in validity checking involving constraints;
        Trac #16263
  6. 14 Feb, 2019 1 commit
    • Simon Peyton Jones's avatar
      Make a smart mkAppTyM · 68278382
      Simon Peyton Jones authored
      This patch finally delivers on Trac #15952.  Specifically
      * Completely remove Note [The tcType invariant], along with
        its complicated consequences (IT1-IT6).
      * Replace Note [The well-kinded type invariant] with:
            Note [The Purely Kinded Type Invariant (PKTI)]
      * Instead, establish the (PKTI) in TcHsType.tcInferApps,
        by using a new function mkAppTyM when building a type
        application.  See Note [mkAppTyM].
      * As a result we can remove the delicate mkNakedXX functions
        entirely.  Specifically, mkNakedCastTy retained lots of
        extremly delicate Refl coercions which just cluttered
        everything up, and(worse) were very vulnerable to being
        silently eliminated by (say) substTy. This led to a
        succession of bug reports.
      The result is noticeably simpler to explain, simpler
      to code, and Richard and I are much more confident that
      it is correct.
      It does not actually fix any bugs, but it brings us closer.
      E.g. I hoped it'd fix #15918 and #15799, but it doesn't quite
      do so.  However, it makes it much easier to fix.
      I also did a raft of other minor refactorings:
      * Use tcTypeKind consistently in the type checker
      * Rename tcInstTyBinders to tcInvisibleTyBinders,
        and refactor it a bit
      * Refactor tcEqType, pickyEqType, tcEqTypeVis
        Simpler, probably more efficient.
      * Make zonkTcType zonk TcTyCons, at least if they have
        any free unification variables -- see zonk_tc_tycon
        in TcMType.zonkTcTypeMapper.
        Not zonking these TcTyCons was actually a bug before.
      * Simplify try_to_reduce_no_cache in TcFlatten (a lot)
      * Combine checkExpectedKind and checkExpectedKindX.
        And then combine the invisible-binder instantation code
        Much simpler now.
      * Fix a little bug in TcMType.skolemiseQuantifiedTyVar.
        I'm not sure how I came across this originally.
      * Fix a little bug in TyCoRep.isUnliftedRuntimeRep
        (the ASSERT was over-zealous).  Again I'm not certain
        how I encountered this.
      * Add a missing solveLocalEqualities in
        I came across this when trying to get level numbers
  7. 03 Dec, 2018 1 commit
    • Simon Peyton Jones's avatar
      Introduce tcTypeKind, and use it · 03d48526
      Simon Peyton Jones authored
      In the type checker Constraint and * are distinct; and the function
      that takes the kind of a type should respect that distinction
      (Trac #15971).
      This patch implements the change:
      * Introduce Type.tcTypeKind, and use it throughout the type
        inference engine
      * Add new Note [Kinding rules for types] for the kinding
        rules, especially for foralls.
      * Redefine
          isPredTy ty = tcIsConstraintKind (tcTypeKind ty)
        (it had a much more complicated definition before)
      Some miscellaneous refactoring
      * Get rid of TyCoRep.isTYPE, Kind.isTYPEApp,
        in favour of TyCoRep.kindRep, kindRep_maybe
      * Rename Type.getRuntimeRepFromKind_maybe
        to getRuntimeRep_maybe
      I did some spot-checks on compiler perf, and it really doesn't
      budge (as expected).
  8. 29 Nov, 2018 1 commit
    • Simon Peyton Jones's avatar
      Taming the Kind Inference Monster · 2257a86d
      Simon Peyton Jones authored
      My original goal was (Trac #15809) to move towards using level numbers
      as the basis for deciding which type variables to generalise, rather
      than searching for the free varaibles of the environment.  However
      it has turned into a truly major refactoring of the kind inference
      Let's deal with the level-numbers part first:
      * Augment quantifyTyVars to calculate the type variables to
        quantify using level numbers, and compare the result with
        the existing approach.  That is; no change in behaviour,
        just a WARNing if the two approaches give different answers.
      * To do this I had to get the level number right when calling
        quantifyTyVars, and this entailed a bit of care, especially
        in the code for kind-checking type declarations.
      * However, on the way I was able to eliminate or simplify
        a number of calls to solveEqualities.
      This work is incomplete: I'm not /using/ level numbers yet.
      When I subsequently get rid of any remaining WARNings in
      quantifyTyVars, that the level-number answers differ from
      the current answers, then I can rip out the current
      "free vars of the environment" stuff.
      Anyway, this led me into deep dive into kind inference for type and
      class declarations, which is an increasingly soggy part of GHC.
      Richard already did some good work recently in
         commit 5e45ad10
         Date:   Thu Sep 13 09:56:02 2018 +0200
          Finish fix for #14880.
          The real change that fixes the ticket is described in
          Note [Naughty quantification candidates] in TcMType.
      but I kept turning over stones. So this patch has ended up
      with a pretty significant refactoring of that code too.
      Kind inference for types and classes
      * Major refactoring in the way we generalise the inferred kind of
        a TyCon, in kcTyClGroup.  Indeed, I made it into a new top-level
        function, generaliseTcTyCon.  Plus a new Note to explain it
        Note [Inferring kinds for type declarations].
      * We decided (Trac #15592) not to treat class type variables specially
        when dealing with Inferred/Specified/Required for associated types.
        That simplifies things quite a bit. I also rewrote
        Note [Required, Specified, and Inferred for types]
      * Major refactoring of the crucial function kcLHsQTyVars:
        I split it into
             kcLHsQTyVars_Cusk  and  kcLHsQTyVars_NonCusk
        because the two are really quite different. The CUSK case is
        almost entirely rewritten, and is much easier because of our new
        decision not to treat the class variables specially
      * I moved all the error checks from tcTyClTyVars (which was a bizarre
        place for it) into generaliseTcTyCon and/or the CUSK case of
        kcLHsQTyVars.  Now tcTyClTyVars is extremely simple.
      * I got rid of all the all the subtleties in tcImplicitTKBndrs. Indeed
        now there is no difference between tcImplicitTKBndrs and
        kcImplicitTKBndrs; there is now a single bindImplicitTKBndrs.
        Same for kc/tcExplicitTKBndrs.  None of them monkey with level
        numbers, nor build implication constraints.  scopeTyVars is gone
        entirely, as is kcLHsQTyVarBndrs. It's vastly simpler.
        I found I could get rid of kcLHsQTyVarBndrs entirely, in favour of
        the bnew bindExplicitTKBndrs.
      * I now deal with the "naughty quantification candidates"
        of the previous patch in candidateQTyVars, rather than in
        quantifyTyVars; see Note [Naughty quantification candidates]
        in TcMType.
        I also killed off closeOverKindsCQTvs in favour of the same
        strategy that we use for tyCoVarsOfType: namely, close over kinds
        at the occurrences.
        And candidateQTyVars no longer needs a gbl_tvs argument.
      * Passing the ContextKind, rather than the expected kind itself,
        to tc_hs_sig_type_and_gen makes it easy to allocate the expected
        result kind (when we are in inference mode) at the right level.
      Type families
      * I did a major rewrite of the impenetrable tcFamTyPats. The result
        is vastly more comprehensible.
      * I got rid of kcDataDefn entirely, quite a big function.
      * I re-did the way that checkConsistentFamInst works, so
        that it allows alpha-renaming of invisible arguments.
      * The interaction of kind signatures and family instances is tricky.
          Type families: see Note [Apparently-nullary families]
          Data families: see Note [Result kind signature for a data family instance]
                         and Note [Eta-reduction for data families]
      * The consistent instantation of an associated type family is tricky.
        See Note [Checking consistent instantiation] and
            Note [Matching in the consistent-instantation check]
        in TcTyClsDecls.  It's now checked in TcTyClsDecls because that is
        when we have the relevant info to hand.
      * I got tired of the compromises in etaExpandFamInst, so I did the
        job properly by adding a field cab_eta_tvs to CoAxBranch.
        See Coercion.etaExpandCoAxBranch.
      tcInferApps and friends
      * I got rid of the mysterious and horrible ClsInstInfo argument
        to tcInferApps, checkExpectedKindX, and various checkValid
        functions.  It was horrible!
      * I got rid of [Type] result of tcInferApps.  This list was used
        only in tcFamTyPats, when checking the LHS of a type instance;
        and if there is a cast in the middle, the list is meaningless.
        So I made tcInferApps simpler, and moved the complexity
        (not much) to tcInferApps.
        Result: tcInferApps is now pretty comprehensible again.
      * I refactored the many function in TcMType that instantiate skolems.
      Smaller things
      * I rejigged the error message in checkValidTelescope; I think it's
        quite a bit better now.
      * checkValidType was not rejecting constraints in a kind signature
           forall (a :: Eq b => blah). blah2
        That led to further errors when we then do an ambiguity check.
        So I make checkValidType reject it more aggressively.
      * I killed off quantifyConDecl, instead calling kindGeneralize
      * I fixed an outright bug in tyCoVarsOfImplic, where we were not
        colleting the tyvar of the kind of the skolems
      * Renamed ClsInstInfo to AssocInstInfo, and made it into its
        own data type
      * Some fiddling around with pretty-printing of family
        instances which was trickier than I thought.  I wanted
        wildcards to print as plain "_" in user messages, although
        they each need a unique identity in the CoAxBranch.
      Some other oddments
      * Refactoring around the trace messages from reportUnsolved.
      * A bit of extra tc-tracing in TcHsSyn.commitFlexi
      This patch fixes a raft of bugs, and includes tests for them.
       * #14887
       * #15740
       * #15764
       * #15789
       * #15804
       * #15817
       * #15870
       * #15874
       * #15881
  9. 24 Nov, 2018 1 commit
  10. 22 Nov, 2018 2 commits
    • David Eichmann's avatar
      Fix unused-import warnings · 6353efc7
      David Eichmann authored
      This patch fixes a fairly long-standing bug (dating back to 2015) in
      RdrName.bestImport, namely
         commit 9376249b
         Author: Simon Peyton Jones <simonpj@microsoft.com>
         Date:   Wed Oct 28 17:16:55 2015 +0000
         Fix unused-import stuff in a better way
      In that patch got the sense of the comparison back to front, and
      thereby failed to implement the unused-import rules described in
        Note [Choosing the best import declaration] in RdrName
      This led to Trac #13064 and #15393
      Fixing this bug revealed a bunch of unused imports in libraries;
      the ones in the GHC repo are part of this commit.
      The two important changes are
      * Fix the bug in bestImport
      * Modified the rules by adding (a) in
           Note [Choosing the best import declaration] in RdrName
        Reason: the previosu rules made Trac #5211 go bad again.  And
        the new rule (a) makes sense to me.
      In unravalling this I also ended up doing a few other things
      * Refactor RnNames.ImportDeclUsage to use a [GlobalRdrElt] for the
        things that are used, rather than [AvailInfo]. This is simpler
        and more direct.
      * Rename greParentName to greParent_maybe, to follow GHC
        naming conventions
      * Delete dead code RdrName.greUsedRdrName
      Bumps a few submodules.
      Reviewers: hvr, goldfire, bgamari, simonmar, jrtc27
      Subscribers: rwbarton, carter
      Differential Revision: https://phabricator.haskell.org/D5312
    • Ryan Scott's avatar
      Overhaul -fprint-explicit-kinds to use VKA · f5d20838
      Ryan Scott authored
      This patch changes the behavior of `-fprint-explicit-kinds`
      so that it displays kind argument using visible kind application.
      In other words, the flag now:
      1. Prints instantiations of specified variables with `@(...)`.
      2. Prints instantiations of inferred variables with `@{...}`.
      In addition, this patch removes the `Use -fprint-explicit-kinds to
      see the kind arguments` error message that often arises when a type
      mismatch occurs due to different kinds. Instead, whenever there is a
      kind mismatch, we now enable the `-fprint-explicit-kinds` flag
      locally to help cue to the programmer where the error lies.
      (See `Note [Kind arguments in error messages]` in `TcErrors`.)
      As a result, these funny `@{...}` things can now appear to the user
      even without turning on the `-fprint-explicit-kinds` flag explicitly,
      so I took the liberty of documenting them in the users' guide.
      Test Plan: ./validate
      Reviewers: goldfire, simonpj, bgamari
      Reviewed By: simonpj
      Subscribers: rwbarton, carter
      GHC Trac Issues: #15871
      Differential Revision: https://phabricator.haskell.org/D5314
  11. 04 Nov, 2018 1 commit
    • Roland Senn's avatar
      Fix for Trac #15611: Scope errors lie about what modules are imported. · 1a3b9bd0
      Roland Senn authored
      For the error message:
          Not in scope X.Y
          Module X does not export Y
          No module named ‘X’ is imported:
      there are 2 cases, where we don't show the last "no module named is imported" line:
      1. If the module X has been imported.
      2. If the module X is the current module. There are 2 subcases:
         2.1 If the unknown module name is in a input source file,
             then we can use the getModule function to get the current module name.
         2.2 If the unknown module name has been entered by the user in GHCi,
             then the getModule function returns something like "interactive:Ghci1",
             and we have to check the current module in the last added entry of
             the HomePackageTable.
      Test Plan: make test TESTS="T15611a T15611b"
      Reviewers: monoidal, hvr, thomie, dfeuer, bgamari, DavidEichmann
      Reviewed By: monoidal, DavidEichmann
      Subscribers: rwbarton, carter
      GHC Trac Issues: #15611
      Differential Revision: https://phabricator.haskell.org/D5284
  12. 29 Oct, 2018 1 commit
    • Tobias Dammers's avatar
      Finish fix for #14880. · 5e45ad10
      Tobias Dammers authored
      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
      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},
  13. 24 Oct, 2018 2 commits
    • Simon Peyton Jones's avatar
      Report a Wanted error even if there are Given ones · 6b1102e2
      Simon Peyton Jones authored
      We suppress some Given errors; see Note [Given errors]
      in TcErrors.  But we must be careful not to suppress
      Wanted errors because of the presence of these Given
      errors -- else we might allow compilation to bogusly
      The rubber hits the road in TcRnTypes.insolubleCt,
      where we don't want to treat Givens as insoluble,
      nor (and this is the new bit) Deriveds that arise
      from Givens.  See Note [Given insolubles] in TcRnTypes.
      This fixes #15767.
    • Simon Peyton Jones's avatar
      Refactor the treatment of predicate types · 0faf7fd3
      Simon Peyton Jones authored
      Trac #15648 showed that GHC was a bit confused about the
      difference between the types for
      * Predicates
      * Coercions
      * Evidence (in the typechecker constraint solver)
      This patch cleans it up. See especially Type.hs
      Note [Types for coercions, predicates, and evidence]
      Particular changes
      * Coercion types (a ~# b) and (a ~#R b) are not predicate types
        (so isPredTy reports False for them) and are not implicitly
        instantiated by the type checker.  This is a real change, but
        it consistently reflects that fact that (~#) and (~R#) really
        are different from predicates.
      * isCoercionType is renamed to isCoVarType
      * During type inference, simplifyInfer, we do /not/ want to infer
        a constraint (a ~# b), because that is no longer a predicate type.
        So we 'lift' it to (a ~ b). See TcType
        Note [Lift equality constaints when quantifying]
      * During type inference for pattern synonyms, we need to 'lift'
        provided constraints of type (a ~# b) to (a ~ b).  See
        Note [Equality evidence in pattern synonyms] in PatSyn
      * But what about (forall a. Eq a => a ~# b)? Is that a
        predicate type?  No -- it does not have kind Constraint.
        Is it an evidence type?  Perhaps, but awkwardly so.
        In the end I decided NOT to make it an evidence type,
        and to ensure the the type inference engine never
        meets it.  This made me /simplify/ the code in
        TcCanonical.makeSuperClasses; see TcCanonical
        Note [Equality superclasses in quantified constraints]
        Instead I moved the special treatment for primitive
        equality to TcInteract.doTopReactOther.  See TcInteract
        Note [Looking up primitive equalities in quantified constraints]
        Also see Note [Evidence for quantified constraints] in Type.
        All this means I can have
           isEvVarType ty = isCoVarType ty || isPredTy ty
        which is nice.
      All in all, rather a lot of work for a small refactoring,
      but I think it's a real improvement.
  14. 15 Sep, 2018 1 commit
    • Ningning Xie's avatar
      Coercion Quantification · ea5ade34
      Ningning Xie authored
      This patch corresponds to #15497.
      According to https://ghc.haskell.org/trac/ghc/wiki/DependentHaskell/Phase2,
       we would like to have coercion quantifications back. This will
      allow us to migrate (~#) to be homogeneous, instead of its current
      heterogeneous definition. This patch is (lots of) plumbing only. There
      should be no user-visible effects.
      An overview of changes:
      - Both `ForAllTy` and `ForAllCo` can quantify over coercion variables,
      but only in *Core*. All relevant functions are updated accordingly.
      - Small changes that should be irrelevant to the main task:
          1. removed dead code `mkTransAppCo` in Coercion
          2. removed out-dated Note Computing a coercion kind and
             roles in Coercion
          3. Added `Eq4` in Note Respecting definitional equality in
             TyCoRep, and updated `mkCastTy` accordingly.
          4. Various updates and corrections of notes and typos.
      - Haddock submodule needs to be changed too.
      This work was completed mostly during Ningning Xie's Google Summer
      of Code, sponsored by Google. It was advised by Richard Eisenberg,
      supported by NSF grant 1704041.
      Test Plan: ./validate
      Reviewers: goldfire, simonpj, bgamari, hvr, erikd, simonmar
      Subscribers: RyanGlScott, monoidal, rwbarton, carter
      GHC Trac Issues: #15497
      Differential Revision: https://phabricator.haskell.org/D5054
  15. 24 Aug, 2018 1 commit
    • Simon Peyton Jones's avatar
      Better error reporting for inaccessible code · ff29fc84
      Simon Peyton Jones authored
      This patch fixes Trac #15558.  There turned out to be
      two distinct problems
      * In TcExpr.tc_poly_expr_nc we had
          tc_poly_expr_nc (L loc expr) res_ty
            = do { traceTc "tcPolyExprNC" (ppr res_ty)
                 ; (wrap, expr')
                     <- tcSkolemiseET GenSigCtxt res_ty $ \ res_ty ->
                        setSrcSpan loc $
                          -- NB: setSrcSpan *after* skolemising,
                          -- so we get better skolem locations
                        tcExpr expr res_ty
        Putting the setSrcSpan inside the tcSkolemise means that
        the location on the Implication constraint is the /call/
        to the function rather than the /argument/ to the call,
        and that is really quite wrong.
        I don't know what Richard's comment NB means -- I moved the
        setSrcSpan outside, and the "binding site" info in error
        messages actually improved.
        The reason I found this is that it affects the span reported
        for Trac #15558.
      * In TcErrors.mkGivenErrorReporter we carefully munge the location
        for an insoluble Given constraint (Note [Inaccessible code]).
        But the 'implic' passed in wasn't necesarily the immediately-
        enclosing implication -- but for location-munging purposes
        it jolly well should be.
        Solution: use the innermost implication. This actually
        simplifies the code -- no need to pass an implication in to
  16. 23 Aug, 2018 1 commit
    • Simon Peyton Jones's avatar
      Accommodate API change in transSuperClasses · 4293a80a
      Simon Peyton Jones authored
      In this patch
          commit 6eabb6dd
          Author: Simon Peyton Jones <simonpj@microsoft.com>
          Date:   Tue Dec 15 14:26:13 2015 +0000
          Allow recursive (undecidable) superclasses
      I changed (transSuperClasses p) to return only the
      superclasses of p, but not p itself. (Previously it always
      returned p as well.)
      The use of transSuperClasses in TcErrors.warnRedundantConstraints
      really needs 'p' in the result -- but I faild to fix this
      call site, and instead crippled the test for Trac #10100.
      This patch sets things right
      * Accomodates the API change
      * Re-enables T10100
      * And thereby fixes Trac #11474
  17. 20 Aug, 2018 1 commit
    • Simon Peyton Jones's avatar
      Initialise cec_suppress properly · ecc0ddf6
      Simon Peyton Jones authored
      In TcErrors, cec_suppress is used to suppress low-priority
      errors in favour of truly insoluble ones.
      But I was failing to initialise it correcly at top level, which
      resulted in Trac #15539.  Easy to fix.
      A few regression tests have fewer errors reported, but that seems to
      be an improvement.
  18. 17 Aug, 2018 1 commit
    • Joachim Breitner's avatar
      Rename SigTv to TyVarTv (#15480) · a50244c6
      Joachim Breitner authored
      because since #15050, these are no longer used in pattern SIGnatures,
      but still in other places where meta-variables should only be unified
      with TYpe VARiables.
      I also found mentions of `SigTv` in parts of the renamer and desugarer
      that do not seem to directly relate to `SigTv` as used in the type
      checker, but rather to uses of `forall a.` in type signatures. I renamed
      these to `ScopedTv`.
      Differential Revision: https://phabricator.haskell.org/D5074
  19. 12 Aug, 2018 1 commit
    • Ryan Scott's avatar
      Suppress redundant givens during error reporting · c552feea
      Ryan Scott authored
      When GHC reports that it cannot solve a constraint in error
      messages, it often reports what given constraints it has in scope.
      Unfortunately, sometimes redundant constraints (like `* ~ *`, from
      #15361) can sneak in. The fix is simple: blast away these redundant
      constraints using `mkMinimalBySCs`.
      Test Plan: make test TEST=T15361
      Reviewers: simonpj, bgamari
      Subscribers: rwbarton, thomie, carter
      GHC Trac Issues: #15361
      Differential Revision: https://phabricator.haskell.org/D5002
  20. 25 Jul, 2018 2 commits
    • Simon Peyton Jones's avatar
      Fix and document cloneWC · 857ef25e
      Simon Peyton Jones authored
      The cloneWC, cloneWanted, cloneImplication family are used by
        * TcHoleErrors
        * TcRule
      to clone the /bindings/ in a constraint, so that solving the
      constraint will not add bindings to the program. The idea is only
      to affect unifications.
      But I had it wrong -- I failed to clone the EvBindsVar of an
      implication.  That gave an assert failure, I think, as well as
      useless dead code.
      The fix is easy.  I'm not adding a test case.
      In the type 'TcEvidence.EvBindsVar', I also renamed the
      'NoEvBindsVar' constructor to 'CoEvBindsVar'.  It's not that we
      have /no/ evidence bindings, just that we can only have coercion
      bindings, done via HoleDest.
    • Simon Peyton Jones's avatar
      Treat isConstraintKind more consistently · c5d31df7
      Simon Peyton Jones authored
      It turned out that we were not being consistent
      about our use of isConstraintKind.
      It's delicate, because the typechecker treats Constraint and Type as
      /distinct/, whereas they are the /same/ in the rest of the compiler
      (Trac #11715).
      And had it wrong, which led to Trac #15412.  This patch does the
      * Rename isConstraintKind      to tcIsConstraintKind
               returnsConstraintKind to tcReturnsConstraintKind
        to emphasise that they use the 'tcView' view of types.
      * Move these functions, and some related ones (tcIsLiftedTypeKind),
        from Kind.hs, to group together in Type.hs, alongside isPredTy.
      It feels very unsatisfactory that these 'tcX' functions live in Type,
      but it happens because isPredTy is called later in the compiler
      too.  But it's a consequence of the 'Constraint vs Type' dilemma.
  21. 24 Jul, 2018 1 commit
    • Ryan Scott's avatar
      Suppress -Winaccessible-code in derived code · 44a7b9ba
      Ryan Scott authored
      It's rather unfortunate that derived code can produce inaccessible
      code warnings (as demonstrated in #8128, #8740, and #15398), since
      the programmer has no control over the generated code. This patch
      aims to suppress `-Winaccessible-code` in all derived code. It
      accomplishes this by doing the following:
      * Generalize the `ic_env :: TcLclEnv` field of `Implication` to
        be of type `Env TcGblEnc TcLclEnv` instead. This way, it also
        captures `DynFlags`, which record the flag state at the time
        the `Implication` was created.
      * When typechecking derived code, turn off `-Winaccessible-code`.
        This way, any insoluble given `Implication`s that are created when
        typechecking this derived code will remember that
        `-Winaccessible-code` was disabled.
      * During error reporting, consult the `DynFlags` of an
        `Implication` before making the decision to report an inaccessible
        code warning.
      Test Plan: make test TEST="T8128 T8740 T15398"
      Reviewers: simonpj, bgamari
      Reviewed By: simonpj
      Subscribers: monoidal, rwbarton, thomie, carter
      GHC Trac Issues: #8128, #8740, #15398
      Differential Revision: https://phabricator.haskell.org/D4993
  22. 08 Jun, 2018 1 commit
  23. 04 Jun, 2018 1 commit
    • Simon Peyton Jones's avatar
      Implement QuantifiedConstraints · 7df58960
      Simon Peyton Jones authored
      We have wanted quantified constraints for ages and, as I hoped,
      they proved remarkably simple to implement.   All the machinery was
      already in place.
      The main ticket is Trac #2893, but also relevant are
        #9123 (especially!  higher kinded roles)
      The wiki page is
      which in turn contains a link to the GHC Proposal where the change
      is specified.
      Here is the relevant Note:
      Note [Quantified constraints]
      The -XQuantifiedConstraints extension allows type-class contexts like
        data Rose f x = Rose x (f (Rose f x))
        instance (Eq a, forall b. Eq b => Eq (f b))
              => Eq (Rose f a)  where
          (Rose x1 rs1) == (Rose x2 rs2) = x1==x2 && rs1 >= rs2
      Note the (forall b. Eq b => Eq (f b)) in the instance contexts.
      This quantified constraint is needed to solve the
       [W] (Eq (f (Rose f x)))
      constraint which arises form the (==) definition.
      Here are the moving parts
        * Language extension {-# LANGUAGE QuantifiedConstraints #-}
          and add it to ghc-boot-th:GHC.LanguageExtensions.Type.Extension
        * A new form of evidence, EvDFun, that is used to discharge
          such wanted constraints
        * checkValidType gets some changes to accept forall-constraints
          only in the right places.
        * Type.PredTree gets a new constructor ForAllPred, and
          and classifyPredType analyses a PredType to decompose
          the new forall-constraints
        * Define a type TcRnTypes.QCInst, which holds a given
          quantified constraint in the inert set
        * TcSMonad.InertCans gets an extra field, inert_insts :: [QCInst],
          which holds all the Given forall-constraints.  In effect,
          such Given constraints are like local instance decls.
        * When trying to solve a class constraint, via
          TcInteract.matchInstEnv, use the InstEnv from inert_insts
          so that we include the local Given forall-constraints
          in the lookup.  (See TcSMonad.getInstEnvs.)
        * topReactionsStage calls doTopReactOther for CIrredCan and
          CTyEqCan, so they can try to react with any given
          quantified constraints (TcInteract.matchLocalInst)
        * TcCanonical.canForAll deals with solving a
          forall-constraint.  See
             Note [Solving a Wanted forall-constraint]
             Note [Solving a Wanted forall-constraint]
        * We augment the kick-out code to kick out an inert
          forall constraint if it can be rewritten by a new
          type equality; see TcSMonad.kick_out_rewritable
      Some other related refactoring
      * Move SCC on evidence bindings to post-desugaring, which fixed
        #14735, and is generally nicer anyway because we can use
        existing CoreSyn free-var functions.  (Quantified constraints
        made the free-vars of an ev-term a bit more complicated.)
      * In LookupInstResult, replace GenInst with OneInst and NotSure,
        using the latter for multiple matches and/or one or more
  24. 03 Jun, 2018 1 commit
    • Tobias Dammers's avatar
      Turn "inaccessible code" error into a warning · 08073e16
      Tobias Dammers authored
      With GADTs, it is possible to write programs such that the type
      constraints make some code branches inaccessible.
      Take, for example, the following program ::
          {-# LANGUAGE GADTs #-}
          data Foo a where
           Foo1 :: Foo Char
           Foo2 :: Foo Int
          data TyEquality a b where
                  Refl :: TyEquality a a
          checkTEQ :: Foo t -> Foo u -> Maybe (TyEquality t u)
          checkTEQ x y = error "unimportant"
          step2 :: Bool
          step2 = case checkTEQ Foo1 Foo2 of
                   Just Refl -> True -- Inaccessible code
                   Nothing -> False
      Clearly, the `Just Refl` case cannot ever be reached, because the `Foo1`
      and `Foo2` constructors say `t ~ Char` and `u ~ Int`, while the `Refl`
      constructor essentially mandates `t ~ u`, and thus `Char ~ Int`.
      Previously, GHC would reject such programs entirely; however, in
      practice this is too harsh. Accepting such code does little harm, since
      attempting to use the "impossible" code will still produce errors down
      the chain, while rejecting it means we cannot legally write or generate
      such code at all.
      Hence, we turn the error into a warning, and provide
      `-Winaccessible-code` to control GHC's behavior upon encountering this
      Test Plan: ./validate
      Reviewers: bgamari
      Reviewed By: bgamari
      Subscribers: rwbarton, thomie, carter
      GHC Trac Issues: #11066
      Differential Revision: https://phabricator.haskell.org/D4744
  25. 30 May, 2018 1 commit
    • Matthías Páll Gissurarson's avatar
      Improved Valid Hole Fits · e0b44e2e
      Matthías Páll Gissurarson authored
      I've changed the name from `Valid substitutions` to `Valid hole fits`,
      since "substitution" already has a well defined meaning within the
      theory. As part of this change, the flags and output is reanamed, with
      substitution turning into hole-fit in most cases. "hole fit" was already
      used internally in the code, it's clear and shouldn't cause any
      In this update, I've also reworked how we manage side-effects in the
      hole we are considering.
      This allows us to consider local bindings such as where clauses and
      arguments to functions, suggesting e.g. `a` for `head (x:xs) where head
      :: [a] -> a`.
      It also allows us to find suggestions such as `maximum` for holes of
      type `Ord a => a -> [a]`, and `max` when looking for a match for the
      hole in `g = foldl1 _`, where `g :: Ord a => [a] -> a`.
      We also show much improved output for refinement hole fits, and
      fixes #14990. We now show the correct type of the function, but we also
      now show what the arguments to the function should be e.g. `foldl1 (_ ::
      Integer -> Integer -> Integer)` when looking for `[Integer] -> Integer`.
      I've moved the bulk of the code from `TcErrors.hs` to a new file,
      `TcHoleErrors.hs`, since it was getting too big to not live on it's own.
      This addresses the considerations raised in #14969, and takes proper
      care to set the `tcLevel` of the variables to the right level before
      passing it to the simplifier.
      We now also zonk the suggestions properly, which improves the output of
      the refinement hole fits considerably.
      This also filters out suggestions from the `GHC.Err` module, since even
      though `error` and `undefined` are indeed valid hole fits, they are
      "trivial", and almost never useful to the user.
      We now find the hole fits using the proper manner, namely by solving
      nested implications. This entails that the givens are passed along using
      the implications the hole was nested in, which in turn should mean that
      there will be fewer weird bugs in the typed holes.
      I've also added a new sorting method (as suggested by SPJ) and sort by
      the size of the types needed to turn the hole fits into the type of the
      hole. This gives a reasonable approximation to relevance, and is much
      faster than the subsumption check. I've also added a flag to toggle
      whether to use this new sorting algorithm (as is done by default) or the
      subsumption algorithm. This fixes #14969
      I've also added documentation for these new flags and update the
      documentation according to the new output.
      Reviewers: bgamari, goldfire
      Reviewed By: bgamari
      Subscribers: simonpj, rwbarton, thomie, carter
      GHC Trac Issues: #14969, #14990, #10946
      Differential Revision: https://phabricator.haskell.org/D4444
  26. 18 May, 2018 1 commit
    • Simon Peyton Jones's avatar
      Orient TyVar/TyVar equalities with deepest on the left · 2bbdd00c
      Simon Peyton Jones authored
      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
      * 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.
  27. 16 May, 2018 1 commit
    • Ryan Scott's avatar
      Fix #15039 by pretty-printing equalities more systematically · 99f8cc84
      Ryan Scott authored
      GHC previously had a handful of special cases for
      pretty-printing equalities in a more user-friendly manner, but they
      were far from comprehensive (see #15039 for an example of where this
      fell apart).
      This patch makes the pretty-printing of equalities much more
      systematic. I've adopted the approach laid out in
      https://ghc.haskell.org/trac/ghc/ticket/15039#comment:4, and updated
      `Note [Equality predicates in IfaceType]` accordingly. We are now
      more careful to respect the properties of the
      `-fprint-explicit-kinds` and `-fprint-equality-relations` flags,
      which led to some improvements in error message outputs.
      Along the way, I also tweaked the error-reporting machinery not to
      print out the type of a typed hole when the type is an unlifted
      equality, since it's kind (`TYPE ('TupleRep '[])`) was more
      confusing than anything.
      Test Plan: make test TEST="T15039a T15039b T15039c T15039d"
      Reviewers: simonpj, goldfire, bgamari
      Reviewed By: simonpj
      Subscribers: rwbarton, thomie, carter
      GHC Trac Issues: #15039
      Differential Revision: https://phabricator.haskell.org/D4696
  28. 15 May, 2018 1 commit
    • Simon Peyton Jones's avatar
      Tidy up error suppression · f49f90bb
      Simon Peyton Jones authored
      Trac #15152 showed that when a flag turned an error into a warning, we
      were still (alas) suppressing subequent errors; includign their
      essential addTcEvBind.  That led (rightly) to a Lint error.
      This patch fixes it, and incidentally tidies up an ad-hoc special
      case of out-of-scope variables (see the old binding for
      'out_of_scope_killer' in 'tryReporters').
      No test, because the problem was only shown up when turning
      inaccessible code into a warning.
  29. 27 Apr, 2018 1 commit
    • Simon Peyton Jones's avatar
      Make out-of-scope errors more prominent · 08003e7f
      Simon Peyton Jones authored
      Generally, when the type checker reports an error, more serious
      ones suppress less serious ones.
      A "variable out of scope" error is arguably the most serious of all,
      so this patch moves it to the front of the list instead of the end.
      This patch also fixes Trac #14149, which had
      -fdefer-out-of-scope-variables, but also had a solid type error.
      As things stood, the type error was not reported at all, and
      compilation "succeeded" with error code 0.  Yikes.
      Note that
      - "Hole errors" (including out of scope) are never suppressed.
        (maybeReportHoleError vs maybeReportError in TcErorrs)
        They can just get drowned by the noise.
      - But with the new orientation, out of scope errors will suppress
        type errors.  That would be easy to change.
  30. 01 Apr, 2018 1 commit
    • Richard Eisenberg's avatar
      Track type variable scope more carefully. · faec8d35
      Richard Eisenberg authored
      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
      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
      Fixes #14066 #14749
      Test cases: dependent/should_compile/{T14066a,T14749},
  31. 23 Mar, 2018 1 commit
    • Ryan Scott's avatar
      Allow PartialTypeSignatures in standalone deriving contexts · affdea82
      Ryan Scott authored
      At its core, this patch is a simple tweak that allows a user
      to write:
      deriving instance _ => Eq (Foo a)
      Which is functionally equivalent to:
      data Foo a = ...
        deriving Eq
      But with the added flexibility that `StandaloneDeriving` gives you
      (namely, the ability to use it anywhere, not just in the same module
      that `Foo` was declared in). This fixes #13324, and should hopefully
      address a use case brought up in #10607.
      Currently, only the use of a single, extra-constraints wildcard is
      permitted in a standalone deriving declaration. Any other wildcard
      is rejected, so things like
      `deriving instance (Eq a, _) => Eq (Foo a)` are currently forbidden.
      There are quite a few knock-on changes brought on by this change:
      * The `HsSyn` type used to represent standalone-derived instances
        was previously `LHsSigType`, which isn't sufficient to hold
        wildcard types. This needed to be changed to `LHsSigWcType` as a
      * Previously, `DerivContext` was a simple type synonym for
        `Maybe ThetaType`, under the assumption that you'd only ever be in
        the `Nothing` case if you were in a `deriving` clause. After this
        patch, that assumption no longer holds true, as you can also be
        in this situation with standalone deriving when an
        extra-constraints wildcard is used.
        As a result, I changed `DerivContext` to be a proper datatype that
        reflects the new wrinkle that this patch adds, and plumbed this
        through the relevant parts of `TcDeriv` and friends.
      * Relatedly, the error-reporting machinery in `TcErrors` also assumed
        that if you have any unsolved constraints in a derived instance,
        then you should be able to fix it by switching over to standalone
        deriving. This was always sound advice before, but with this new
        feature, it's possible to have unsolved constraints even when
        you're standalone-deriving something!
        To rectify this, I tweaked some constructors of `CtOrigin` a bit
        to reflect this new subtlety.
      This requires updating the Haddock submodule. See my fork at
      Test Plan: ./validate
      Reviewers: simonpj, goldfire, bgamari
      Reviewed By: simonpj
      Subscribers: goldfire, rwbarton, thomie, mpickering, carter
      GHC Trac Issues: #13324
      Differential Revision: https://phabricator.haskell.org/D4383
  32. 18 Feb, 2018 1 commit
    • Matthías Páll Gissurarson's avatar
      Add valid refinement substitution suggestions for typed holes · 918c0b39
      Matthías Páll Gissurarson authored
      This adds valid refinement substitution suggestions for typed holes and
      documentation thereof.
      Inspired by Agda's refinement facilities, this extends the typed holes
      feature to be able to search for valid refinement substitutions, which
      are substitutions that have one or more holes in them.
      When the flag `-frefinement-level-substitutions=n` where `n > 0` is
      passed, we also look for valid refinement substitutions, i.e.
      substitutions that are valid, but adds more holes. Consider the
        f :: [Integer] -> Integer
        f = _
      Here the valid substitutions suggested will be (with the new
      `-funclutter-valid-substitutions` flag for less verbosity set):
        Valid substitutions include
          f :: [Integer] -> Integer
          product :: forall (t :: * -> *).
                    Foldable t => forall a. Num a => t a -> a
          sum :: forall (t :: * -> *).
                Foldable t => forall a. Num a => t a -> a
          maximum :: forall (t :: * -> *).
                    Foldable t => forall a. Ord a => t a -> a
          minimum :: forall (t :: * -> *).
                    Foldable t => forall a. Ord a => t a -> a
          head :: forall a. [a] -> a
          (Some substitutions suppressed; use -fmax-valid-substitutions=N or
      When the `-frefinement-level-substitutions=1` flag is given, we
      additionally compute and report valid refinement substitutions:
        Valid refinement substitutions include
          foldl1 _ :: forall (t :: * -> *).
                      Foldable t => forall a. (a -> a -> a) -> t a -> a
          foldr1 _ :: forall (t :: * -> *).
                      Foldable t => forall a. (a -> a -> a) -> t a -> a
          head _ :: forall a. [a] -> a
          last _ :: forall a. [a] -> a
          error _ :: forall (a :: TYPE r).
                      GHC.Stack.Types.HasCallStack => [Char] -> a
          errorWithoutStackTrace _ :: forall (a :: TYPE r). [Char] -> a
          (Some refinement substitutions suppressed; use
      -fmax-refinement-substitutions=N or -fno-max-refinement-substitutions)
      Which are substitutions with holes in them. This allows e.g. beginners
      to discover the fold functions and similar.
      We find these refinement suggestions by considering substitutions that
      don't fit the type of the hole, but ones that would fit if given an
      additional argument. We do this by creating a new type variable with
      newOpenFlexiTyVarTy (e.g. `t_a1/m[tau:1]`), and then considering
      substitutions of the type `t_a1/m[tau:1] -> v` where `v` is the type of
      the hole. Since the simplifier is free to unify this new type variable
      with any type (and it is cloned before each check to avoid
      side-effects), we can now discover any identifiers that would fit if
      given another identifier of a suitable type. This is then generalized
      so that we can consider any number of additional arguments by setting
      the `-frefinement-level-substitutions` flag to any number, and then
      considering substitutions like e.g. `foldl _ _` with two additional
      This can e.g. help beginners discover the `fold` functions.
      This could also help more advanced users figure out which morphisms
      they can use when arrow chasing.
      Then you could write `m = _ . m2 . m3` where `m2` and `m3` are some
      morphisms, and not only get exact fits, but also help in finding
      morphisms that might get you a little bit closer to where you want to
      go in the diagram.
      Reviewers: bgamari
      Reviewed By: bgamari
      Subscribers: rwbarton, thomie, carter
      Differential Revision: https://phabricator.haskell.org/D4357
  33. 08 Feb, 2018 1 commit
    • Simon Peyton Jones's avatar
      Fix isDroppableCt (Trac #14763) · 6edafe3b
      Simon Peyton Jones authored
      When finishing up an implication constraint, it's a bit tricky to
      decide which Derived constraints to retain (for error reporting) and
      which to discard.  I got this wrong in commit
         (Remove wc_insol from WantedConstraints)
      The particular problem in Trac #14763 was that we were reporting as an
      error a fundep-generated constraint
        (ex ~ T)
      where 'ex' is an existentially-bound variable in a pattern match.
      But this isn't really an error at all.
      This patch fixes the problem. Indeed, since I had to understand
      this rather tricky code, I took the opportunity to clean it up
      and document better.  See
        isDroppableCt :: Ct -> Bool
      and Note [Dropping derived constraints]
      I also removed wl_deriv altogether from the WorkList data type.  It
      was there in the hope of gaining efficiency by not even processing
      lots of derived constraints, but it has turned out that most derived
      constraints (notably equalities) must be processed anyway; see
      Note [Prioritise equalities] in TcSMonad.
      The two are coupled because to decide which constraints to put in
      wl_deriv I was using another variant of isDroppableCt.  Now it's much
      simpler -- and perhaps even more efficient too.
  34. 26 Jan, 2018 2 commits
    • Matthías Páll Gissurarson's avatar
      Sort valid substitutions for typed holes by "relevance" · cbdea959
      Matthías Páll Gissurarson authored
      This is an initial attempt at tackling the issue of how to order the
      suggestions provided by the valid substitutions checker, by sorting
      them by creating a graph of how they subsume each other. We'd like to
      order them in such a manner that the most "relevant" suggestions are
      displayed first, so that the suggestion that the user might be looking
      for is displayed before more far-fetched suggestions (and thus also
      displayed when they'd otherwise be cut-off by the
      `-fmax-valid-substitutions` limit). The previous ordering was based on
      the order in which the elements appear in the list of imports, which I
      believe is less correlated with relevance than this ordering.
      A drawback of this approach is that, since we now want to sort the
      elements, we can no longer "bail out early" when we've hit the
      `-fmax-valid-substitutions` limit.
      Reviewers: bgamari, dfeuer
      Reviewed By: dfeuer
      Subscribers: dfeuer, rwbarton, thomie, carter
      Differential Revision: https://phabricator.haskell.org/D4326
    • Joachim Breitner's avatar
      Turn EvTerm (almost) into CoreExpr (#14691) · 0e022e56
      Joachim Breitner authored
      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 8fa4bf9a.
      Differential Revision: https://phabricator.haskell.org/D4341
  35. 18 Jan, 2018 1 commit
    • Matthías Páll Gissurarson's avatar
      Inform hole substitutions of typeclass constraints (fixes #14273). · 1e14fd3e
      Matthías Páll Gissurarson authored
      This implements SPJ's suggestion on the ticket (#14273). We find the
      relevant constraints (ones that whose free unification variables are all
      mentioned in the type of the hole), and then clone the free unification
      variables of the hole and the relevant constraints. We then add a
      subsumption constraints and run the simplifier, and then check whether
      all the constraints were solved.
      Reviewers: bgamari
      Reviewed By: bgamari
      Subscribers: RyanGlScott, rwbarton, thomie, carter
      GHC Trac Issues: #14273
      Differential Revision: https://phabricator.haskell.org/D4315
  36. 03 Jan, 2018 1 commit