1. 11 Apr, 2018 1 commit
  2. 10 Apr, 2018 12 commits
  3. 09 Apr, 2018 3 commits
  4. 07 Apr, 2018 8 commits
  5. 06 Apr, 2018 3 commits
  6. 05 Apr, 2018 1 commit
  7. 03 Apr, 2018 1 commit
  8. 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
  9. 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
  10. 31 Mar, 2018 2 commits
    • Tamar Christina's avatar
      testsuite: allow accepting of fine grained results [skip ci] · ca535f95
      Tamar Christina authored
      Summary:
      Sometimes we need to be able to mass accept changes that are platform
      specific and that can't be normalized away using our string formatters.
      
      e.g. differences in I/O manager errors or behaviors. This allows one
      to do so easier than before and less error prone.
      
      I have updated the docs and made it clear this should only be used
      when a normalizer won't work:
      
      https://ghc.haskell.org/trac/ghc/wiki/Building/RunningTests/Updating
      
      Test Plan: Manually tested while working on new I/O manager
      
      Reviewers: bgamari
      
      Subscribers: thomie, carter
      
      Differential Revision: https://phabricator.haskell.org/D4549
      ca535f95
    • Tamar Christina's avatar
      Remove MAX_PATH restrictions from RTS, I/O manager and various utilities · 4de585a5
      Tamar Christina authored
      Summary:
      This shims out fopen and sopen so that they use modern APIs under the hood
      along with namespaced paths.
      
      This lifts the MAX_PATH restrictions from Haskell programs and makes the new
      limit ~32k.
      
      There are only some slight caveats that have been documented.
      
      Some utilities have not been upgraded such as lndir, since all these things are
      different cabal packages I have been forced to copy the source in different places
      which is less than ideal. But it's the only way to keep sdist working.
      
      Test Plan: ./validate
      
      Reviewers: hvr, bgamari, erikd, simonmar
      
      Reviewed By: bgamari
      
      Subscribers: rwbarton, thomie, carter
      
      GHC Trac Issues: #10822
      
      Differential Revision: https://phabricator.haskell.org/D4416
      4de585a5