1. 07 Apr, 2018 6 commits
  2. 06 Apr, 2018 3 commits
  3. 05 Apr, 2018 1 commit
  4. 03 Apr, 2018 1 commit
  5. 02 Apr, 2018 5 commits
    • Richard Eisenberg's avatar
      Fix #14991. · d8d4266b
      Richard Eisenberg authored
      It turns out that solveEqualities really does need to use simpl_top.
      I thought that solveWanteds would be enough, and no existing test
      case showed up the different. #14991 shows that we need simpl_top.
      Easy enough to fix.
      
      test case: dependent/should_compile/T14991
      d8d4266b
    • Richard Eisenberg's avatar
      Mark test as expected to pass. · ddf89557
      Richard Eisenberg authored
      This fixes the SplitWD "unexpected pass". This test was fixed
      by ef443820 and somehow fell
      through my validation cracks.
      ddf89557
    • Simon Peyton Jones's avatar
      SpecConstr: accommodate casts in value arguments · 5ab8094e
      Simon Peyton Jones authored
      This commit:
      
        commit fb050a33
        Author: Simon Peyton Jones <simonpj@microsoft.com>
        Date:   Thu Oct 12 11:00:19 2017 +0100
      
        Do not bind coercion variables in SpecConstr rules
      
      arranged to reject any SpecConstr call pattern that mentioned
      a coercion in the pattern.
      
      There was a good reason for that
      -- see Note [SpecConstr and casts] --
      but I didn't realise how important it was to accept patterns
      that mention casts in /terms/.  Trac #14936 showed this up.
      
      This patch just narrows the restriction to discard only
      the cases where the coercion is mentioned only in types.
      Fortunately that was pretty easy to do.
      5ab8094e
    • Simon Peyton Jones's avatar
      Allow unpacking of single-data-con GADTs · 9187d5fb
      Simon Peyton Jones authored
      Trac #14978 pointed out that single-constructor GADTs should be
      unpackable without trouble.
      
      Acutally I realise that even existentials should be unpackable
      too, but that's a bit more work, so it's not part of this patch.
      
      See Note [Unpacking GADTs and existentials] in MkId.
      9187d5fb
    • Richard Eisenberg's avatar
      Test #14884, #14969 · 07abff71
      Richard Eisenberg authored
      These were fixed by faec8d35
      
      test cases: typecheck/should_fail/T14884
                  ghci/scripts/T14969
      07abff71
  6. 01 Apr, 2018 4 commits
    • Richard Eisenberg's avatar
      Clarify comments around dropping Derived constraints · 1845d1bc
      Richard Eisenberg authored
      [skip ci]
      1845d1bc
    • Richard Eisenberg's avatar
      3eaa55dc
    • Richard Eisenberg's avatar
      Apply the interim fix for #14119 to liftCoMatch · ef443820
      Richard Eisenberg authored
      Matching in the presence of casts can happen in liftCoMatch, too.
      ef443820
    • 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
  7. 31 Mar, 2018 3 commits
  8. 30 Mar, 2018 1 commit
  9. 29 Mar, 2018 5 commits
  10. 27 Mar, 2018 11 commits