1. 21 Mar, 2019 1 commit
    • Ryan Scott's avatar
      Reject nested predicates in impredicativity checking · 8d18a873
      Ryan Scott authored
      When GHC attempts to unify a metavariable with a type containing
      foralls, it will be rejected as an occurrence of impredicativity.
      GHC was /not/ extending the same treatment to predicate types, such
      as in the following (erroneous) example from #11514:
      
      ```haskell
      foo :: forall a. (Show a => a -> a) -> ()
      foo = undefined
      ```
      
      This will attempt to instantiate `undefined` at
      `(Show a => a -> a) -> ()`, which is impredicative. This patch
      catches impredicativity arising from predicates in this fashion.
      
      Since GHC is pickier about impredicative instantiations, some test
      cases needed to be updated to be updated so as not to fall afoul of
      the new validity check. (There were a surprising number of
      impredicative uses of `undefined`!) Moreover, the `T14828` test case
      now has slightly less informative types shown with `:print`. This is
      due to a a much deeper issue with the GHCi debugger (see #14828).
      
      Fixes #11514.
      8d18a873
  2. 27 Jul, 2017 1 commit
    • 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
  3. 27 Mar, 2017 1 commit
    • Simon Peyton Jones's avatar
      Fix error-message suppress on given equalities · e0ad55f8
      Simon Peyton Jones authored
      I'd got the logic slightly wrong when reporting type errors
      for insoluble 'given' equalities.  We suppress insoluble givens
      under some circumstances (see Note [Given errors]), but we then
      suppressed subsequent 'wanted' errors because the (suppressed)
      'given' error "won".  Result: no errors at all :-(.
      
      This patch fixes it and
       - Renames TcType.isTyVarUnderDatatype to the more
         perspicuous TcType.isInsolubleOccursCheck
      
      In doing this I realise that I don't understand why we need
      to keep the insolubles partitioned out separately at all...
      but that is for another day.
      e0ad55f8
  4. 27 Jan, 2016 1 commit
    • eir@cis.upenn.edu's avatar
      Refactor the typechecker to use ExpTypes. · 00cbbab3
      eir@cis.upenn.edu authored
      The idea here is described in [wiki:Typechecker]. Briefly,
      this refactor keeps solid track of "synthesis" mode vs
      "checking" in GHC's bidirectional type-checking algorithm.
      When in synthesis mode, the expected type is just an IORef
      to write to.
      
      In addition, this patch does a significant reworking of
      RebindableSyntax, allowing much more freedom in the types
      of the rebindable operators. For example, we can now have
      `negate :: Int -> Bool` and
      `(>>=) :: m a -> (forall x. a x -> m b) -> m b`. The magic
      is in tcSyntaxOp.
      
      This addresses tickets #11397, #11452, and #11458.
      
      Tests:
        typecheck/should_compile/{RebindHR,RebindNegate,T11397,T11458}
        th/T11452
      00cbbab3
  5. 04 Nov, 2014 1 commit
  6. 28 Apr, 2014 1 commit
    • Simon Peyton Jones's avatar
      Do type-class defaulting even if there are insoluble constraints · ba2e2014
      Simon Peyton Jones authored
      The argument in Trac #9033 is very compelling: we should not report 20
      errors, fix one, and have the other 19 disappear.  They were spurious
      in the first place.
      
      The fix was easy; do type-class defaulting uncondionally, rather than
      only if there are no insoluble constraints.
      
      See Note [When to do type-class defaulting] in TcSimplify.
      
      Error messages generally improve, especially tc211 which actually
      had an example of precisely this phenomenon.
      ba2e2014
  7. 10 Apr, 2014 1 commit
    • Simon Peyton Jones's avatar
      Fix egregious blunder in the type flattener · b8132a9d
      Simon Peyton Jones authored
      In tidying up the flattener I introduced an error that no
      regression test caught, giving rise to Trac #8978, #8979.
      It shows up if you have a type synonym whose RHS mentions
      type functions, such sas
           type family F a
           type T a = (F a, a)   -- This synonym isn't properly flattened
      
      The fix is easy, but sadly the bug is in the released GHC 7.8.1
      b8132a9d
  8. 25 Feb, 2014 1 commit
  9. 14 Sep, 2013 1 commit
  10. 24 Feb, 2013 1 commit
  11. 08 Jan, 2013 1 commit
  12. 31 Oct, 2012 1 commit
  13. 21 Sep, 2012 1 commit
  14. 10 Apr, 2012 1 commit