1. 10 Jul, 2018 8 commits
    • Richard Eisenberg's avatar
      Kind-check CUSK associated types separately · 030211d2
      Richard Eisenberg authored
      Previously, we kind-checked associated types while while still
      figuring out the kind of a CUSK class. This caused trouble, as
      documented in Note [Don't process associated types in kcLHsQTyVars]
      in TcTyClsDecls. This commit moves this process after the initial
      kind of the class is determined.
      
      Fixes #15142.
      
      Test case: indexed-types/should_compile/T15142.hs
      030211d2
    • Richard Eisenberg's avatar
      Unwrap casts before checking vars in eager unifier · 042df603
      Richard Eisenberg authored
      Previously, checking whether (tv |> co) ~ (tv |> co) got deferred,
      because we looked for vars before stripping casts. (The left type
      would get stripped, and then tv ~ (tv |> co) would scare the occurs-
      checker.)
      
      This opportunity for improvement presented itself in other work.
      This is just an optimization. Some programs can now report more
      errors simultaneously.
      042df603
    • Simon Peyton Jones's avatar
      Optional context for a quantified constraint · 8ec29460
      Simon Peyton Jones authored
      This is a documentation-only fix, addressing Trac #15354.
      8ec29460
    • Simon Peyton Jones's avatar
      Add nakedSubstTy and use it in TcHsType.tcInferApps · 5067b205
      Simon Peyton Jones authored
      This was a tricky one.
      
      During type checking we maintain TcType:
         Note [The well-kinded type invariant]
      That is, types are well-kinded /without/ zonking.
      
      But in tcInferApps we were destroying that invariant by calling
      substTy, which in turn uses smart constructors, which eliminate
      apparently-redundant Refl casts.
      
      This is horribly hard to debug beause they really are Refls and
      so it "ought" to be OK to discard them. But it isn't, as the
      above Note describes in some detail.
      
      Maybe we should review the invariant?  But for now I just followed
      it, tricky thought it is.
      
      This popped up because (for some reason) when I fixed Trac #15343,
      that exposed this bug by making test polykinds/T14174a fail (in
      Trac #14174 which indeed has the same origin).
      
      So this patch fixes a long standing and very subtle bug.
      
      One interesting point: I defined nakedSubstTy in a few lines by
      using the generic mapType stuff.  I note that the "normal"
      TyCoRep.substTy does /not/ use mapType.  But perhaps it should:
      substTy has lots of $! strict applications in it, and they could
      all be eliminated just by useing the StrictIdentity monad.  And
      that'd make it much easier to experiment with switching between
      strict and lazy versions.
      5067b205
    • Simon Peyton Jones's avatar
      More tc-tracing · 03d72683
      Simon Peyton Jones authored
      And I added some HasDebugCallStack constraints to tcExpectedKind
      and related functions too.
      03d72683
    • Simon Peyton Jones's avatar
      Fix decompsePiCos and visible type application · aedbf7f1
      Simon Peyton Jones authored
      Trac #15343 was caused by two things
      
      First, in TcHsType.tcHsTypeApp, which deals with the type argment
      in visible type application, we were failing to call
      solveLocalEqualities. But the type argument is like a user type
      signature so it's at least inconsitent not to do so.
      
      I thought that would nail it.  But it didn't. It turned out that we
      were ended up calling decomposePiCos on a type looking like this
          (f |> co) Int
      
      where co :: (forall a. ty) ~ (t1 -> t2)
      
      Now, 'co' is insoluble, and we'll report that later.  But meanwhile
      we don't want to crash in decomposePiCos.
      
      My fix involves keeping track of the type on both sides of the
      coercion, and ensuring that the outer shape matches before
      decomposing.  I wish there was a simpler way to do this. But
      I think this one is at least robust.
      
      I suppose it is possible that the decomposePiCos fix would
      have cured the original report, but I'm leaving the one-line
      tcHsTypeApp fix in too because it just seems more consistent.
      aedbf7f1
    • Simon Peyton Jones's avatar
      More refactoring in TcValidity · fd0f0334
      Simon Peyton Jones authored
      This patch responds to Trac #15334 by making it an error to
      write an instance declaration for a tuple constraint like
      (Eq [a], Show [a]).
      
      I then discovered that instance validity checking was
      scattered betweeen TcInstDcls and TcValidity, so I took
      the time to bring it all together, into
        TcValidity.checkValidInstHead
      
      In doing so I discovered that there are lot of special
      cases.   I have not changed them, but at least they are
      all laid out clearly now.
      fd0f0334
    • Ningning Xie's avatar
      Refactor coercion rule · 55a3f855
      Ningning Xie authored
      Summary:
      The patch is an attempt on #15192.
      
      It defines a new coercion rule
      
      ```
       | GRefl Role Type MCoercion
      ```
      
      which correspondes to the typing rule
      
      ```
           t1 : k1
        ------------------------------------
        GRefl r t1 MRefl: t1 ~r t1
      
           t1 : k1       co :: k1 ~ k2
        ------------------------------------
        GRefl r t1 (MCo co) : t1 ~r t1 |> co
      ```
      
      MCoercion wraps a coercion, which might be reflexive (MRefl)
      or not (MCo co). To know more about MCoercion see #14975.
      
      We keep Refl ty as a special case for nominal reflexive coercions,
      naemly, Refl ty :: ty ~n ty.
      
      This commit is meant to be a general performance improvement,
      but there are a few regressions. See #15192, comment:13 for
      more information.
      
      Test Plan: ./validate
      
      Reviewers: bgamari, goldfire, simonpj
      
      Subscribers: rwbarton, thomie, carter
      
      GHC Trac Issues: #15192
      
      Differential Revision: https://phabricator.haskell.org/D4747
      55a3f855
  2. 08 Jul, 2018 1 commit
  3. 06 Jul, 2018 11 commits
  4. 05 Jul, 2018 10 commits
    • Ryan Scott's avatar
      Accept new stdout for tcrun045 · 45f00268
      Ryan Scott authored
      The stdout produced by test tcrun045 changed in commit
      45f44e2c. The change appears to be
      benign, so I've decided to accept it.
      45f00268
    • Ryan Scott's avatar
      Comment out a pprTrace · 9b26aa09
      Ryan Scott authored
      This was introduced in commit
      45f44e2c, but it results in lots of
      "check_class ~" messages when validating. I've decided to just
      comment it out.
      9b26aa09
    • Ryan Scott's avatar
      Make ppr_tc_args aware of -fprint-explicit-kinds · dbdcacfc
      Ryan Scott authored
      Summary:
      `ppr_tc_args` was printing invisible kind arguments even
      when `-fprint-explicit-kinds` wasn't enabled. Easily fixed.
      
      Test Plan: make test TEST=T15341
      
      Reviewers: goldfire, bgamari, simonpj
      
      Reviewed By: simonpj
      
      Subscribers: simonpj, rwbarton, thomie, carter
      
      GHC Trac Issues: #15341
      
      Differential Revision: https://phabricator.haskell.org/D4932
      dbdcacfc
    • Ryan Scott's avatar
      Fix #15331 with careful blasts of parenthesizeHsType · b6a33861
      Ryan Scott authored
      Summary:
      Another `-ddump-splices` bug that can be solved with more
      judicious use of parentheses.
      
      Test Plan: make test TEST=T15331
      
      Reviewers: goldfire, bgamari, alanz, tdammers
      
      Reviewed By: tdammers
      
      Subscribers: rwbarton, thomie, carter
      
      GHC Trac Issues: #15331
      
      Differential Revision: https://phabricator.haskell.org/D4920
      b6a33861
    • Ryan Scott's avatar
      Parenthesize rank-n contexts in Convert · 57733978
      Ryan Scott authored
      Summary: A simple oversight.
      
      Test Plan: make test TEST=T15324
      
      Reviewers: goldfire, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: rwbarton, thomie, carter
      
      GHC Trac Issues: #15324
      
      Differential Revision: https://phabricator.haskell.org/D4910
      57733978
    • Ryan Scott's avatar
      Fix newtype instance GADTs · 92751866
      Ryan Scott authored
      Summary: This was taken from Richard's branch, which in turn was
      submitted to Phab by Matthew, which in turn was commandeered by Ryan.
      
      This fixes an issue with newtype instances in which too many
      coercions were being applied in the worker. This fixes the issue by
      removing the data family instance axiom from the worker and moving
      to the wrapper. Moreover, we now require all newtype instances
      to have wrappers, for symmetry with data instances.
      
      Reviewers: goldfire, bgamari, simonpj, mpickering
      
      Reviewed By: mpickering
      
      Subscribers: simonpj, rwbarton, thomie, carter
      
      GHC Trac Issues: #15318
      
      Differential Revision: https://phabricator.haskell.org/D4902
      92751866
    • Ryan Scott's avatar
      Instantiate GND bindings with an explicit type signature · 132273f3
      Ryan Scott authored
      Summary:
      Before, we were using visible type application to apply
      impredicative types to `coerce` in
      `GeneralizedNewtypeDeriving`-generated bindings. This approach breaks
      down when combined with `QuantifiedConstraints` in certain ways,
      which #14883 and #15290 provide examples of. See
      Note [GND and QuantifiedConstraints] for all the gory details.
      
      To avoid this issue, we instead use an explicit type signature to
      instantiate each GND binding, and use that to bind any type variables
      that might be bound by a class method's type signature. This reduces
      the need to impredicative type applications, and more importantly,
      makes the programs from #14883 and #15290 work again.
      
      Test Plan: make test TEST="T15290b T15290c T15290d T14883"
      
      Reviewers: simonpj, bgamari
      
      Reviewed By: simonpj
      
      Subscribers: rwbarton, thomie, carter
      
      GHC Trac Issues: #14883, #15290
      
      Differential Revision: https://phabricator.haskell.org/D4895
      132273f3
    • Ryan Scott's avatar
      Fix #15308 by suppressing invisble args more rigorously · 93b7ac8d
      Ryan Scott authored
      Summary:
      There was a buglet in `stripInvisArgs` (which is part of the
      pretty-printing pipeline for types) in which only invisble arguments
      which came before any visible arguments would be suppressed, but any
      invisble arguments that came //after// visible ones would still be
      printed, even if `-fprint-explicit-kinds`  wasn't enabled.
      The fix is simple: make `stripInvisArgs` recursively process the
      remaining types even after a visible argument is encountered.
      
      Test Plan: make test TEST=T15308
      
      Reviewers: goldfire, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: simonpj, rwbarton, thomie, carter
      
      GHC Trac Issues: #15308
      
      Differential Revision: https://phabricator.haskell.org/D4891
      93b7ac8d
    • Ryan Scott's avatar
      Fix #15307 by making nlHsFunTy parenthesize more · 59a15a56
      Ryan Scott authored
      Summary:
      `nlHsFunTy` wasn't parenthesizing its arguments at all,
      which led to `-ddump-deriv` producing incorrectly parenthesized
      types (since it uses `nlHsFunTy` to construct those types), as
      demonstrated in #15307. Fix this by changing `nlHsFunTy` to add
      parentheses à la `ppr_ty`: always parenthesizing the argument type
      with function precedence, and recursively processing the result type,
      adding parentheses for each function type it encounters.
      
      Test Plan: make test TEST=T14578
      
      Reviewers: bgamari
      
      Reviewed By: bgamari
      
      Subscribers: rwbarton, thomie, carter
      
      GHC Trac Issues: #15307
      
      Differential Revision: https://phabricator.haskell.org/D4890
      59a15a56
    • Simon Peyton Jones's avatar
      Refactor validity checking for constraints · 45f44e2c
      Simon Peyton Jones authored
      There are several changes here.
      
      * TcInteract has gotten too big, so I moved all the class-instance
        matching out of TcInteract into a new module ClsInst. It parallels
        the FamInst module.
      
        The main export of ClsInst is matchGlobalInst.
        This now works in TcM not TcS.
      
      * A big reason to make matchGlobalInst work in TcM is that we can
        then use it from TcValidity.checkSimplifiableClassConstraint.
        That extends checkSimplifiableClassConstraint to work uniformly
        for built-in instances, which means that we now get a warning
        if we have givens (Typeable x, KnownNat n); see Trac #15322.
      
      * This change also made me refactor LookupInstResult, in particular
        by adding the InstanceWhat field.  I also changed the name of the
        type to ClsInstResult.
      
        Then instead of matchGlobalInst reporting a staging error (which is
        inappropriate for the call from TcValidity), we can do so in
        TcInteract.checkInstanceOK.
      
      * In TcValidity, we now check quantified constraints for termination.
        For example, this signature should be rejected:
           f :: (forall a. Eq (m a) => Eq (m a)) => blah
        as discussed in Trac #15316.   The main change here is that
        TcValidity.check_pred_help now uses classifyPredType, and has a
        case for ForAllPred which it didn't before.
      
        This had knock-on refactoring effects in TcValidity.
      45f44e2c
  5. 04 Jul, 2018 8 commits
  6. 01 Jul, 2018 1 commit
  7. 29 Jun, 2018 1 commit