Fix isLiftedType_maybe and handle fallout

As #20837 pointed out, `isLiftedType_maybe` returned `Just False` in
many situations where it should return `Nothing`, because it didn't
take into account type families or type variables.

In this patch, we fix this issue. We rename `isLiftedType_maybe` to
`typeLevity_maybe`, which now returns a `Levity` instead of a boolean.
We now return `Nothing` for types with kinds of the form
`TYPE (F a1 ... an)` for a type family `F`, as well as
`TYPE (BoxedRep l)` where `l` is a type variable.

This fix caused several other problems, as other parts of the compiler
were relying on `isLiftedType_maybe` returning a `Just` value, and were
now panicking after the above fix. There were two main situations in
which panics occurred:

  1. Issues involving the let/app invariant. To uphold that invariant,
     we need to know whether something is lifted or not. If we get an
     answer of `Nothing` from `isLiftedType_maybe`, then we don't know
     what to do. As this invariant isn't particularly invariant, we
     can change the affected functions to not panic, e.g. by behaving
     the same in the `Just False` case and in the `Nothing` case
     (meaning: no observable change in behaviour compared to before).

  2. Typechecking of data (/newtype) constructor patterns. Some programs
     involving patterns with unknown representations were accepted, such
     as T20363. Now that we are stricter, this caused further issues,
     culminating in Core Lint errors. However, the behaviour was
     incorrect the whole time; the incorrectness only being revealed by
     this change, not triggered by it.

     This patch fixes this by overhauling where the representation
     polymorphism involving pattern matching are done. Instead of doing
     it in `tcMatches`, we instead ensure that the `matchExpected`
     functions such as `matchExpectedFunTys`, `matchActualFunTySigma`,
     `matchActualFunTysRho` allow return argument pattern types which
     have a fixed RuntimeRep (as defined in Note [Fixed RuntimeRep]).
     This ensures that the pattern matching code only ever handles types
     with a known runtime representation. One exception was that
     patterns with an unknown representation type could sneak in via
     `tcConPat`, which points to a missing representation-polymorphism
     check, which this patch now adds.

     This means that we now reject the program in #20363, at least until
     we implement PHASE 2 of FixedRuntimeRep (allowing type families in
     RuntimeRep positions). The aforementioned refactoring, in which
     checks have been moved to `matchExpected` functions, is a first
     step in implementing PHASE 2 for patterns.

Fixes #20837

4 files changed, 4 insertions, 4 deletions

diff --git a/testsuite/tests/typecheck/should_fail/FD1.stderr b/testsuite/tests/typecheck/should_fail/FD1.stderr
index 64a01c43e1..b0beafb416 100644
--- a/testsuite/tests/typecheck/should_fail/FD1.stderr
+++ b/testsuite/tests/typecheck/should_fail/FD1.stderr
@@ -5,6 +5,6 @@ FD1.hs:16:1: error:
         the type signature for:
           plus :: forall a. E a (Int -> Int) => Int -> a
         at FD1.hs:15:1-38
-    • The equation(s) for ‘plus’ have two value arguments,
+    • The equation for ‘plus’ has two value arguments,
         but its type ‘Int -> a’ has only one
     • Relevant bindings include plus :: Int -> a (bound at FD1.hs:16:1)
diff --git a/testsuite/tests/typecheck/should_fail/tcfail001.stderr b/testsuite/tests/typecheck/should_fail/tcfail001.stderr
index 7f49c869ee..3403057fa9 100644
--- a/testsuite/tests/typecheck/should_fail/tcfail001.stderr
+++ b/testsuite/tests/typecheck/should_fail/tcfail001.stderr
@@ -2,7 +2,7 @@
 tcfail001.hs:9:2: error:
     • Couldn't match expected type: [a]
                   with actual type: [a0] -> [a1]
-    • The equation(s) for ‘op’ have one value argument,
+    • The equation for ‘op’ has one value argument,
         but its type ‘[a]’ has none
       In the instance declaration for ‘A [a]’
     • Relevant bindings include op :: [a] (bound at tcfail001.hs:9:2)
diff --git a/testsuite/tests/typecheck/should_fail/tcfail140.stderr b/testsuite/tests/typecheck/should_fail/tcfail140.stderr
index d40b317130..da0141da67 100644
--- a/testsuite/tests/typecheck/should_fail/tcfail140.stderr
+++ b/testsuite/tests/typecheck/should_fail/tcfail140.stderr
@@ -34,5 +34,5 @@ tcfail140.hs:17:8: error:
 
 tcfail140.hs:20:1: error:
     • Couldn't match expected type ‘Int’ with actual type ‘p0 -> Bool’
-    • The equation(s) for ‘g’ have two value arguments,
+    • The equation for ‘g’ has two value arguments,
         but its type ‘Int -> Int’ has only one
diff --git a/testsuite/tests/typecheck/should_fail/tcfail175.stderr b/testsuite/tests/typecheck/should_fail/tcfail175.stderr
index 90ec5b13a5..38597e1487 100644
--- a/testsuite/tests/typecheck/should_fail/tcfail175.stderr
+++ b/testsuite/tests/typecheck/should_fail/tcfail175.stderr
@@ -6,7 +6,7 @@ tcfail175.hs:11:1: error:
         the type signature for:
           evalRHS :: forall a. Int -> a
         at tcfail175.hs:10:1-19
-    • The equation(s) for ‘evalRHS’ have three value arguments,
+    • The equation for ‘evalRHS’ has three value arguments,
         but its type ‘Int -> a’ has only one
     • Relevant bindings include
         evalRHS :: Int -> a (bound at tcfail175.hs:11:1)