1. 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.
      857ef25e
    • 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
      following:
      
      * 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.
      c5d31df7
  2. 24 Jul, 2018 1 commit
  3. 26 Jun, 2018 1 commit
  4. 19 Jun, 2018 1 commit
  5. 14 Jun, 2018 1 commit
    • Vladislav Zavialov's avatar
      Embrace -XTypeInType, add -XStarIsType · d650729f
      Vladislav Zavialov authored
      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
      d650729f
  6. 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
        #5927
        #8516
        #9123 (especially!  higher kinded roles)
        #14070
        #14317
      
      The wiki page is
        https://ghc.haskell.org/trac/ghc/wiki/QuantifiedConstraints
      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
      this:
      
        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
        unifiers
      7df58960
  7. 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
      confusion.
      
      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
      e0b44e2e
  8. 23 May, 2018 1 commit
    • Simon Peyton Jones's avatar
      Remove special case from TcTyVar level check · 49a832dd
      Simon Peyton Jones authored
      In TcMType.writeMetaTyVarRef we have an assertion
      check, level_check_ok, that the type being written
      to a unification variable is not deeper than the level
      of the unification varaible itself.
      
      This check used to have a special case for fmv/fsk
      flatten vars, but this commit changed fmv/fsks to have
      an ordinary level number:
      
          commit 2bbdd00c
          Author: Simon Peyton Jones <simonpj@microsoft.com>
          Date:   Fri May 18 08:43:11 2018 +0100
      
          Orient TyVar/TyVar equalities with deepest on the left
      
      So we can delete the isFlattenTyVar special case from
      the level_check_ok assertion.  Simpler, less ad hoc.
      49a832dd
  9. 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
        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.
      2bbdd00c
  10. 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
      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}
      faec8d35
  11. 26 Mar, 2018 1 commit
    • Richard Eisenberg's avatar
      Fix #12919 by making the flattener homegeneous. · e3dbb44f
      Richard Eisenberg authored
      This changes a key invariant of the flattener. Previously,
      flattening a type meant flattening its kind as well. But now,
      flattening is always homogeneous -- that is, the kind of the
      flattened type is the same as the kind of the input type.
      This is achieved by various wizardry in the TcFlatten.flatten_many
      function, as described in Note [flatten_many].
      
      There are several knock-on effects, including some refactoring
      in the canonicalizer to take proper advantage of the flattener's
      changed behavior. In particular, the tyvar case of can_eq_nc' no
      longer needs to take casts into account.
      
      Another effect is that flattening a tyconapp might change it
      into a casted tyconapp. This might happen if the result kind
      of the tycon contains a variable, and that variable changes
      during flattening. Because the flattener is homogeneous, it tacks
      on a cast to keep the tyconapp kind the same. However, this
      is problematic when flattening CFunEqCans, which need to have
      an uncasted tyconapp on the LHS and must remain homogeneous.
      The solution is a more involved canCFunEqCan, described in
      Note [canCFunEqCan].
      
      This patch fixes #13643 (as tested in typecheck/should_compile/T13643)
      and the panic in typecheck/should_compile/T13822 (as reported in #14024).
      Actually, there were two bugs in T13822: the first was just some
      incorrect logic in tryFill (part of the unflattener) -- also fixed
      in this patch -- and the other was the main bug fixed in this ticket.
      
      The changes in this patch exposed a long-standing flaw in OptCoercion,
      in that breaking apart an AppCo sometimes has unexpected effects on
      kinds. See new Note [EtaAppCo] in OptCoercion, which explains the
      problem and fix.
      
      Also here is a reversion of the major change in
      09bf135a, affecting ctEvCoercion.
      It turns out that making the flattener homogeneous changes the
      invariants on the algorithm, making the change in that patch
      no longer necessary.
      
      This patch also fixes:
        #14038 (dependent/should_compile/T14038)
        #13910 (dependent/should_compile/T13910)
        #13938 (dependent/should_compile/T13938)
        #14441 (typecheck/should_compile/T14441)
        #14556 (dependent/should_compile/T14556)
        #14720 (dependent/should_compile/T14720)
        #14749 (typecheck/should_compile/T14749)
      
      Sadly, this patch negatively affects performance of type-family-
      heavy code. The following patch fixes these performance degradations.
      However, the performance fixes are somewhat invasive and so I've
      kept them as a separate patch, labeling this one as [skip ci] so
      that validation doesn't fail on the performance cases.
      e3dbb44f
  12. 26 Jan, 2018 1 commit
    • 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
      0e022e56
  13. 09 Jan, 2018 1 commit
    • Simon Peyton Jones's avatar
      Fix two more bugs in partial signatures · 1577908f
      Simon Peyton Jones authored
      These were shown up by Trac #14643
      
      Bug 1: if we had a single partial signature for
      two functions
         f, g :: forall a. _ -> a
      then we made two different SigTvs but with the sane Name.
      This was jolly confusing and ultimately led to deeply bogus
      results with Any's appearing in the resulting program. Yikes.
      Fix: clone the quantified variables in TcSigs.tcInstSig (as
      indeed its name suggests).
      
      Bug 2: we were not eliminating duplicate/superclass constraints
      in the partial signatures of a mutually recursive group.
      
      Easy to fix: we are already doing dup/superclass elim in
      TcSimplify.decideQuantification.  So we move the partial-sig
      constraints there too.
      1577908f
  14. 21 Dec, 2017 2 commits
    • Simon Peyton Jones's avatar
      Fix floating of equalities · f5cf9d1a
      Simon Peyton Jones authored
      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.
      f5cf9d1a
    • Simon Peyton Jones's avatar
      Refactor coercion holes · a492af06
      Simon Peyton Jones authored
      In fixing Trac #14584 I found that it would be /much/ more
      convenient if a "hole" in a coercion (much like a unification
      variable in a type) acutally had a CoVar associated with it
      rather than just a Unique.  Then I can ask what the free variables
      of a coercion is, and get a set of CoVars including those
      as-yet-un-filled in holes.
      
      Once that is done, it makes no sense to stuff coercion holes
      inside UnivCo.  They were there before so we could know the
      kind and role of a "hole" coercion, but once there is a CoVar
      we can get that info from the CoVar.  So I removed HoleProv
      from UnivCoProvenance and added HoleCo to Coercion.
      
      In summary:
      
      * Add HoleCo to Coercion and remove HoleProv from UnivCoProvanance
      
      * Similarly in IfaceCoercion
      
      * Make CoercionHole have a CoVar in it, not a Unique
      
      * Make tyCoVarsOfCo return the free coercion-hole variables
        as well as the ordinary free CoVars.  Similarly, remember
        to zonk the CoVar in a CoercionHole
      
      We could go further, and remove CoercionHole as a distinct type
      altogther, just collapsing it into HoleCo.  But I have not done
      that yet.
      a492af06
  15. 15 Dec, 2017 1 commit
    • Richard Eisenberg's avatar
      Add some commentary re: fix to #11203 · 3910d3e2
      Richard Eisenberg authored
      The fix for #11203 prohibits duplicate SigTvs in non-CUSK kind
      signatures by checking for duplicates after type inference is
      done. This works well. GHC also checks for duplicate SigTvs
      after working with partial type signatures (another place where
      SigTvs arise). However, neither fix eliminates this whole class
      of problems (because doing so would be heavier than we would
      like). So, this comment adds a warning to users of newSigTyVar
      to be aware of problems with duplicates.
      3910d3e2
  16. 11 Dec, 2017 2 commits
  17. 11 Oct, 2017 2 commits
    • Simon Peyton Jones's avatar
      Remove wc_insol from WantedConstraints · f20cf982
      Simon Peyton Jones authored
      This patch is a pure refactoring, which I've wanted to do for
      some time.  The main payload is
      
      * Remove the wc_insol field from WantedConstraints;
        instead put all the insolubles in wc_simple
      
      * Remove inert_insols from InertCans
        Instead put all the insolubles in inert_irreds
      
      * Add a cc_insol flag to CIrredCan, to record that
        the constraint is definitely insoluble
      
      Reasons
      
      * Quite a bit of code gets slightly simpler
      * Fewer concepts to keep separate
      * Insolubles don't happen at all in production code that is
        just being recompiled, so previously there was a lot of
        moving-about of empty sets
      
      A couple of error messages acutally improved.
      f20cf982
    • Simon Peyton Jones's avatar
      Change "cobox" to "co" in debug output · 79ae03aa
      Simon Peyton Jones authored
      These coercions are /not/ boxed, so "cobox" is positively misleading.
      And it's longer than necessary.
      79ae03aa
  18. 25 Sep, 2017 1 commit
    • Simon Peyton Jones's avatar
      Deal with large extra-contraints wildcards · 3c74a512
      Simon Peyton Jones authored
      For reasons explained in TcHsType
      Note [Extra-constraint holes in partial type signatures],
      if we had
        f :: (_) => blahs
      and the '_' was filled in by more than a 62-tuple of contraints,
      GHC crashed.
      
      The same Note explains the hacky solution I have adopted to
      evade this.  Maybe there is some better way, but I couldn't
      see one that didn't involve a great deal of work. And the problem
      is a very narrow one!  If the hack bites us we'll need to think
      again.
      3c74a512
  19. 19 Sep, 2017 1 commit
    • Herbert Valerio Riedel's avatar
      compiler: introduce custom "GhcPrelude" Prelude · f63bc730
      Herbert Valerio Riedel authored
      This switches the compiler/ component to get compiled with
      -XNoImplicitPrelude and a `import GhcPrelude` is inserted in all
      modules.
      
      This is motivated by the upcoming "Prelude" re-export of
      `Semigroup((<>))` which would cause lots of name clashes in every
      modulewhich imports also `Outputable`
      
      Reviewers: austin, goldfire, bgamari, alanz, simonmar
      
      Reviewed By: bgamari
      
      Subscribers: goldfire, rwbarton, thomie, mpickering, bgamari
      
      Differential Revision: https://phabricator.haskell.org/D3989
      f63bc730
  20. 15 Sep, 2017 1 commit
  21. 29 Aug, 2017 1 commit
  22. 27 Jul, 2017 1 commit
    • Richard Eisenberg's avatar
      Fix #13819 by refactoring TypeEqOrigin.uo_thing · c2417b87
      Richard Eisenberg authored
      The uo_thing field of TypeEqOrigin is used to track the
      "thing" (either term or type) that has the type (kind) stored
      in the TypeEqOrigin fields. Previously, this was sometimes a
      proper Core Type, which needed zonking and tidying. Now, it
      is only HsSyn: much simpler, and the error messages now use
      the user-written syntax.
      
      But this aspect of uo_thing didn't cause #13819; it was the
      sibling field uo_arity that did. uo_arity stored the number
      of arguments of uo_thing, useful when reporting something
      like "should have written 2 fewer arguments". We wouldn't want
      to say that if the thing didn't have two arguments. However,
      in practice, GHC was getting this wrong, and this message
      didn't seem all that helpful. Furthermore, the calculation
      of the number of arguments is what caused #13819 to fall over.
      This patch just removes uo_arity. In my opinion, the change
      to error messages is a nudge in the right direction.
      
      Test case: typecheck/should_fail/T13819
      c2417b87
  23. 03 Jul, 2017 1 commit
  24. 26 May, 2017 1 commit
    • Simon Peyton Jones's avatar
      Re-engineer Given flatten-skolems · 8dc6d645
      Simon Peyton Jones authored
      The big change here is to fix an outright bug in flattening of Givens,
      albeit one that is very hard to exhibit.  Suppose we have the constraint
          forall a. (a ~ F b) => ..., (forall c. ....(F b)...) ...
      
      Then
       - we'll flatten the (F) b to a fsk, say  (F b ~ fsk1)
       - we'll rewrite the (F b) inside the inner implication to 'fsk1'
       - when we leave the outer constraint we are suppose to unflatten;
         but that fsk1 will still be there
       - if we re-simplify the entire outer implication, we'll re-flatten
         the Given (F b) to, say, (F b ~ fsk2)
      Now we have two fsks standing for the same thing, and that is very
      wrong.
      
      Solution: make fsks behave more like fmvs:
       - A flatten-skolem is now a MetaTyVar, whose MetaInfo is FlatSkolTv
       - We "fill in" that meta-tyvar when leaving the implication
       - The old FlatSkol form of TcTyVarDetails is gone completely
       - We track the flatten-skolems for the current implication in
         a new field of InertSet, inert_fsks.
      
      See Note [The flattening story] in TcFlatten.
      
      In doing this I found various other things to fix:
      
      * I removed the zonkSimples from TcFlatten.unflattenWanteds; it wasn't
        needed.   But I added one in TcSimplify.floatEqualities, which does
        the zonk precisely when it is needed.
      
      * Trac #13674 showed up a case where we had
           - an insoluble Given,   e.g.  a ~ [a]
           - the same insoluble Wanted   a ~ [a]
        We don't use the Given to rewwrite the Wanted (obviously), but
        we therefore ended up reporting
            Can't deduce (a ~ [a]) from (a ~ [a])
        which is silly.
      
        Conclusion: when reporting errors, make the occurs check "win"
        See Note [Occurs check wins] in TcErrors
      8dc6d645
  25. 29 Apr, 2017 1 commit
  26. 13 Apr, 2017 1 commit
    • Simon Peyton Jones's avatar
      Remove dead quantifyTyVars · fbb27d77
      Simon Peyton Jones authored
      This patch
      
      * removes a function TcMType.quantifyTyVars
        that was never called
      
      * renames quantifyZonkedTyVars to quantifyTyVars
      
      Plus a few comments.  No functional change at all
      fbb27d77
  27. 06 Apr, 2017 1 commit
    • Simon Peyton Jones's avatar
      Yet another attempt at inferring the right quantification · bac95f9d
      Simon Peyton Jones authored
      TcSimplify.decideQuantification is truly a tricky function!
      Trac #13509 showed that we were being over-eager with defaulting
      of runtime-rep variables (levity polymorphism), which meant that
      a program was wrongly rejected, and with a very odd error message
      (c.f. Trac #13530)
      
      I spent an unreasonably long time figuring out how to fix this
      in a decent way, and ended up with a major refactoring of
      decideQuantification, with a kock-on effect in simplifyInfer.
      
      It is at least a bit more comprehensible now; but I still
      can't say I like it.
      bac95f9d
  28. 27 Mar, 2017 1 commit
  29. 17 Mar, 2017 1 commit
  30. 10 Mar, 2017 2 commits
    • Simon Peyton Jones's avatar
      Improve error messages for skolems · 48d1866e
      Simon Peyton Jones authored
      In error messages like this
          • Couldn't match type ‘c’ with ‘f0 (a -> b)’
            ‘c’ is a rigid type variable bound by
              the type signature for:
                f :: ((a -> b) -> b) -> forall c. c -> a
      
      we need to take case both to actually show that 'forall c',
      and to make sure that its name lines with the 'c' in the
      error message.
      
      This has been shaky for some time, and this commit puts it on solid
      ground.  See TcRnTypes: Note [SigSkol SkolemInfo]
      
      The main changes are
      
      * SigSkol gets an extra field that records the way in which the
        type signature was skolemised.
      
      * The type in SigSkol is now the /un/-skolemised version
      
      * pprSkolemInfo uses the info to make the tidy type line up
        nicely
      
      Lots of error message wibbles!
      48d1866e
    • Simon Peyton Jones's avatar
      Fix TcSimplify.decideQuantification for kind variables · 7e96526a
      Simon Peyton Jones authored
      TcSimplify.decideQuantification was doing the Wrong Thing when
      "growing" the type variables to quantify over. We were trying to do
      this on a tyvar set where we'd split off the dependent type varaibles;
      and we just got it wrong.  A kind variable wasn't being generalised
      properly, with confusing knock on consequences.
      
      All this led to Trac #13371 and Trac #13393.
      
      This commit tidies it all up:
      
      * The type TcDepVars is renamed as CandidateQTvs;
        and splitDepVarsOfType to candidateQTyVarsOfType
      
      * The code in TcSimplify.decideQuantification is simpler.
        It no longer does the tricky "grow" stuff over TcDepVars.
        Instead it use ordinary VarSets (thereby eliminating the
        nasty growThetaTyVarsDSet) and uses that to filter the
        result of candidateQTyVarsOfType.
      
      * I documented that candidateQTyVarsOfType returns the type
        variables in a good order in which to quantify, and rewrote
        it to use an accumulator pattern, so that we would predicatably
        get left-to-right ordering.
      
      In doing all this I also made UniqDFM behave a little more nicely:
      
      * When inserting an element that is there already, keep the old tag,
        while still overwriting with the new value.
      
      * This means that when doing udfmToList we get back elements in the
        order they were originally inserted, rather than in reverse order.
      
      It's not a big deal, but in a subsequent commit I use it to improve
      the order of type variables in inferred types.
      
      All this led to a lot of error message wibbles:
       - changing the order of quantified variables
       - changing the order in which instances are listed in GHCi
       - changing the tidying of variables in typechecker erors
      
      There's a submodule update for 'array' because one of its tests
      has an error-message change.
      
      I may not have associated all of them with the correct commit.
      7e96526a
  31. 01 Mar, 2017 1 commit
    • David Feuer's avatar
      Upgrade UniqSet to a newtype · cbe569a5
      David Feuer authored
      The fundamental problem with `type UniqSet = UniqFM` is that `UniqSet`
      has a key invariant `UniqFM` does not. For example, `fmap` over
      `UniqSet` will generally produce nonsense.
      
      * Upgrade `UniqSet` from a type synonym to a newtype.
      
      * Remove unused and shady `extendVarSet_C` and `addOneToUniqSet_C`.
      
      * Use cached unique in `tyConsOfType` by replacing
        `unitNameEnv (tyConName tc) tc` with `unitUniqSet tc`.
      
      Reviewers: austin, hvr, goldfire, simonmar, niteria, bgamari
      
      Reviewed By: niteria
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D3146
      cbe569a5
  32. 12 Feb, 2017 1 commit
  33. 24 Jan, 2017 1 commit
  34. 19 Jan, 2017 1 commit
    • Richard Eisenberg's avatar
      Update levity polymorphism · e7985ed2
      Richard Eisenberg authored
      This commit implements the proposal in
      https://github.com/ghc-proposals/ghc-proposals/pull/29 and
      https://github.com/ghc-proposals/ghc-proposals/pull/35.
      
      Here are some of the pieces of that proposal:
      
      * Some of RuntimeRep's constructors have been shortened.
      
      * TupleRep and SumRep are now parameterized over a list of RuntimeReps.
      * This
      means that two types with the same kind surely have the same
      representation.
      Previously, all unboxed tuples had the same kind, and thus the fact
      above was
      false.
      
      * RepType.typePrimRep and friends now return a *list* of PrimReps. These
      functions can now work successfully on unboxed tuples. This change is
      necessary because we allow abstraction over unboxed tuple types and so
      cannot
      always handle unboxed tuples specially as we did before.
      
      * We sometimes have to create an Id from a PrimRep. I thus split PtrRep
      * into
      LiftedRep and UnliftedRep, so that the created Ids have the right
      strictness.
      
      * The RepType.RepType type was removed, as it didn't seem to help with
      * much.
      
      * The RepType.repType function is also removed, in favor of typePrimRep.
      
      * I have waffled a good deal on whether or not to keep VoidRep in
      TyCon.PrimRep. In the end, I decided to keep it there. PrimRep is *not*
      represented in RuntimeRep, and typePrimRep will never return a list
      including
      VoidRep. But it's handy to have in, e.g., ByteCodeGen and friends. I can
      imagine another design choice where we have a PrimRepV type that is
      PrimRep
      with an extra constructor. That seemed to be a heavier design, though,
      and I'm
      not sure what the benefit would be.
      
      * The last, unused vestiges of # (unliftedTypeKind) have been removed.
      
      * There were several pretty-printing bugs that this change exposed;
      * these are fixed.
      
      * We previously checked for levity polymorphism in the types of binders.
      * But we
      also must exclude levity polymorphism in function arguments. This is
      hard to check
      for, requiring a good deal of care in the desugarer. See Note [Levity
      polymorphism
      checking] in DsMonad.
      
      * In order to efficiently check for levity polymorphism in functions, it
      * was necessary
      to add a new bit of IdInfo. See Note [Levity info] in IdInfo.
      
      * It is now safe for unlifted types to be unsaturated in Core. Core Lint
      * is updated
      accordingly.
      
      * We can only know strictness after zonking, so several checks around
      * strictness
      in the type-checker (checkStrictBinds, the check for unlifted variables
      under a ~
      pattern) have been moved to the desugarer.
      
      * Along the way, I improved the treatment of unlifted vs. banged
      * bindings. See
      Note [Strict binds checks] in DsBinds and #13075.
      
      * Now that we print type-checked source, we must be careful to print
      * ConLikes correctly.
      This is facilitated by a new HsConLikeOut constructor to HsExpr.
      Particularly troublesome
      are unlifted pattern synonyms that get an extra void# argument.
      
      * Includes a submodule update for haddock, getting rid of #.
      
      * New testcases:
        typecheck/should_fail/StrictBinds
        typecheck/should_fail/T12973
        typecheck/should_run/StrictPats
        typecheck/should_run/T12809
        typecheck/should_fail/T13105
        patsyn/should_fail/UnliftedPSBind
        typecheck/should_fail/LevPolyBounded
        typecheck/should_compile/T12987
        typecheck/should_compile/T11736
      
      * Fixed tickets:
        #12809
        #12973
        #11736
        #13075
        #12987
      
      * This also adds a test case for #13105. This test case is
      * "compile_fail" and
      succeeds, because I want the testsuite to monitor the error message.
      When #13105 is fixed, the test case will compile cleanly.
      e7985ed2
  35. 02 Dec, 2016 1 commit