1. 27 Jul, 2017 6 commits
    • Richard Eisenberg's avatar
      Preserve CoVar uniques during pretty printing · bb2a446a
      Richard Eisenberg authored
      Previously, we did this for Types, but not for Coercions.
      bb2a446a
    • Richard Eisenberg's avatar
      Don't tidy vars when dumping a type · ef39af72
      Richard Eisenberg authored
      This makes variables print more consistenty in, say,
      -ddump-tc-trace.
      ef39af72
    • Richard Eisenberg's avatar
      Test #11672 in typecheck/should_fail/T11672. · 9a549756
      Richard Eisenberg authored
      I believe this was fixed with the fix for #11198.
      9a549756
    • Richard Eisenberg's avatar
      Fix #11400, #11560 by documenting an infelicity. · c9667d32
      Richard Eisenberg authored
      Really, the fix for both of these is #11307.
      c9667d32
    • Richard Eisenberg's avatar
      Improve error messages around kind mismatches. · 8e15e3d3
      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}
      8e15e3d3
    • Gabor Greif's avatar
      Remove unneeded import · 4a264157
      Gabor Greif authored
      4a264157
  2. 26 Jul, 2017 7 commits
    • Ryan Scott's avatar
      Fix #13968 by consulting isBuiltInOcc_maybe · d774b4e2
      Ryan Scott authored
      Summary:
      We were unconditionally reporting `Illegal binding of built-in syntax`
      in an error message, but this error doesn't make sense in certain Template
      Haskell scenarios which can trigger it. Let's give a more sensible error
      message by first checking if the name we're binding really is built-in syntax,
      using the handy `isBuiltInOcc_maybe` function.
      
      Test Plan: make test TEST=T13968
      
      Reviewers: bgamari, austin, goldfire
      
      Reviewed By: goldfire
      
      Subscribers: goldfire, rwbarton, thomie
      
      GHC Trac Issues: #13968
      
      Differential Revision: https://phabricator.haskell.org/D3789
      d774b4e2
    • Gabor Greif's avatar
      Fix note references and some typos · 362339dd
      Gabor Greif authored
      362339dd
    • Simon Peyton Jones's avatar
      Test Trac #14033 · d31181b9
      Simon Peyton Jones authored
      d31181b9
    • Simon Peyton Jones's avatar
      Comments only · f959624f
      Simon Peyton Jones authored
      f959624f
    • Simon Peyton Jones's avatar
      Comments and tc-tracing only · 6386fc32
      Simon Peyton Jones authored
      6386fc32
    • Simon Peyton Jones's avatar
      Fix binder visiblity for default methods · 75bf11c0
      Simon Peyton Jones authored
      Trac #13998 showed that default methods were getting bogus tyvar
      binder visiblity info; and that it matters in the code genreated
      by the default-method fill-in mechanism
      
      * The actual fix: in TcTyDecls.mkDefaultMethodType, make TyVarBinders
        with the right visibility info by getting TyConBinders from the
        class TyCon.  (Previously we made up visiblity info, but that
        caused #13998.)
      
      * Define TyCon.tyConTyVarBinders :: [TyConBinder] -> [TyVarBinder]
        which can build correct forall binders for
          a) default methods (Trac #13998)
          b) data constructors
        This was originally BuildTyCl.mkDataConUnivTyVarBinders
      
      * Move mkTyVarBinder, mkTyVarBinders from Type to Var
      75bf11c0
    • Simon Peyton Jones's avatar
      746ab0b4
  3. 25 Jul, 2017 7 commits
  4. 24 Jul, 2017 10 commits
  5. 23 Jul, 2017 10 commits