Treat isConstraintKind more consistently
authorSimon Peyton Jones <simonpj@microsoft.com>
Wed, 25 Jul 2018 10:35:43 +0000 (11:35 +0100)
committerBen Gamari <ben@smart-cactus.org>
Thu, 2 Aug 2018 02:42:22 +0000 (22:42 -0400)
commit6a7cb80648253ebcc84be5f11e2cc78eae085aa8
tree1e5179ce4388c7c98ec80f48a8567a2c3097e4dc
parente649085bb35628e10b08a9a1ef27095ad0510b40
Treat isConstraintKind more consistently

It turned out that we were not being consistent
about our use of isConstraintKind.

It's delicate, because the typechecker treats Constraint and Type as
/distinct/, whereas they are the /same/ in the rest of the compiler
(Trac #11715).

And had it wrong, which led to Trac #15412.  This patch does the
following:

* Rename isConstraintKind      to tcIsConstraintKind
         returnsConstraintKind to tcReturnsConstraintKind
  to emphasise that they use the 'tcView' view of types.

* Move these functions, and some related ones (tcIsLiftedTypeKind),
  from Kind.hs, to group together in Type.hs, alongside isPredTy.

It feels very unsatisfactory that these 'tcX' functions live in Type,
but it happens because isPredTy is called later in the compiler
too.  But it's a consequence of the 'Constraint vs Type' dilemma.

(cherry picked from commit c5d31df70b16dc346b5860077c8bbe585ddb7a78)
16 files changed:
compiler/typecheck/TcErrors.hs
compiler/typecheck/TcHsType.hs
compiler/typecheck/TcInstDcls.hs
compiler/typecheck/TcInteract.hs
compiler/typecheck/TcMType.hs
compiler/typecheck/TcSplice.hs
compiler/typecheck/TcTyClsDecls.hs
compiler/typecheck/TcType.hs
compiler/typecheck/TcValidity.hs
compiler/types/Kind.hs
compiler/types/TyCoRep.hs
compiler/types/Type.hs
compiler/types/Unify.hs
testsuite/tests/rename/should_fail/T5513.stderr
testsuite/tests/typecheck/should_compile/T15412.hs [new file with mode: 0644]
testsuite/tests/typecheck/should_compile/all.T