1. 28 Sep, 2017 1 commit
    • Simon Marlow's avatar
      mkDataConRep: fix bug in strictness signature (#14290) · a0671e2d
      Simon Marlow authored
      The strictness signature for a data con wrapper wasn't including any
      dictionary arguments, which meant that bangs on the fields of a
      constructor with an existential context would be moved to the wrong
      fields.  See T14290 for an example.
      
      Test Plan:
      * New test T14290
      * validate
      
      Reviewers: simonpj, niteria, austin, bgamari, erikd
      
      Reviewed By: simonpj, bgamari
      
      Subscribers: rwbarton, thomie
      
      GHC Trac Issues: #14290
      
      Differential Revision: https://phabricator.haskell.org/D4040
      
      (cherry picked from commit 5935acdb)
      a0671e2d
  2. 27 Sep, 2017 4 commits
  3. 26 Sep, 2017 5 commits
  4. 19 Sep, 2017 16 commits
  5. 31 Aug, 2017 1 commit
    • Richard Eisenberg's avatar
      Improve error messages around kind mismatches. · 6a024a55
      Richard Eisenberg authored
      Previously, when canonicalizing (or unifying, in uType) a
      heterogeneous equality, we emitted a kind equality and used the
      resulting coercion to cast one side of the heterogeneous equality.
      
      While sound, this led to terrible error messages. (See the bugs
      listed below.) The problem is that using the coercion built from
      the emitted kind equality is a bit like a wanted rewriting a wanted.
      The solution is to keep heterogeneous equalities as irreducible.
      
      See Note [Equalities with incompatible kinds] in TcCanonical.
      
      This commit also removes a highly suspicious switch to FM_SubstOnly
      when flattening in the kinds of a type variable. I have no idea
      why this was there, other than as a holdover from pre-TypeInType.
      I've not left a Note because there is simply no reason I can conceive
      of that the FM_SubstOnly should be there.
      
      One challenge with this patch is that the emitted derived equalities
      might get emitted several times: when a heterogeneous equality is
      in an implication and then gets floated out from the implication,
      the Derived is present both in and out of the implication. This
      causes a duplicate error message. (Test case:
      typecheck/should_fail/T7368) Solution: track the provenance of
      Derived constraints and refuse to float out a constraint that has
      an insoluble Derived.
      
      Lastly, this labels one test (dependent/should_fail/RAE_T32a)
      as expect_broken, because the problem is really #12919. The
      different handling of constraints in this patch exposes the error.
      
      This fixes bugs #11198, #12373, #13530, and #13610.
      
      test cases:
      typecheck/should_fail/{T8262,T8603,tcail122,T12373,T13530,T13610}
      
      (cherry picked from commit 8e15e3d3)
      6a024a55
  6. 29 Aug, 2017 3 commits
    • Tamar Christina's avatar
      Fix decomposition error on Windows · 625bea00
      Tamar Christina authored
      Summary:
      Fix the path decomposition error that occurs when the Symlink resolver
      fails. `Win32.try` throws an exception, so catch it and assume the path
      isn't a symlink to use the old behavior.
      
      Test Plan: ./validate
      
      Reviewers: austin, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: rwbarton, thomie
      
      GHC Trac Issues: #14159
      
      Differential Revision: https://phabricator.haskell.org/D3891
      
      (cherry picked from commit 3c6b2fc3)
      625bea00
    • Simon Peyton Jones's avatar
      Small refactor of getRuntimeRep · cbf47238
      Simon Peyton Jones authored
      Instead of using a string argument, use HasDebugCallStack.
      (Oddly, some functions were using both!)
      
      Plus, use getRuntimeRep rather than getRuntimeRep_maybe when
      if the caller panics on Nothing. Less code, and a better debug
      stack.
      
      (cherry picked from commit a6c448b4)
      cbf47238
    • Simon Peyton Jones's avatar
      Use a well-kinded substitution to instantiate · d913594f
      Simon Peyton Jones authored
      In tcDataConPat we were creating an ill-kinded substitution
      -- or at least one that is well kinded only after you have solved
      other equalities.  THat led to a crash, because the instantiated
      data con type was ill-kinded.
      
      This patch guarantees that the instantiating substitution is
      well-kinded.
      
      Fixed Trac #14154
      
      (cherry picked from commit 4455c86d)
      d913594f
  7. 25 Aug, 2017 9 commits
  8. 22 Aug, 2017 1 commit