Make mkFunCo take AnonArgFlags into account
Previously, whenever `mkFunCo` would produce reflexive coercions, it would use `mkVisFunTy` to produce the kind of the coercion. However, `mkFunCo` is also used to produce coercions between types of the form `ty1 => ty2` in certain places. This has the unfortunate side effect of causing the type of the coercion to appear as `ty1 -> ty2` in certain error messages, as spotted in #21328. This patch address this by changing replacing the use of `mkVisFunTy` with `mkFunctionType` in `mkFunCo`. `mkFunctionType` checks the kind of `ty1` and makes the function arrow `=>` instead of `->` if `ty1` has kind `Constraint`, so this should always produce the correct `AnonArgFlag`. As a result, this patch fixes part (2) of #21328. This is not the only possible way to fix #21328, as the discussion on that issue lists some possible alternatives. Ultimately, it was concluded that the alternatives would be difficult to maintain, and since we already use `mkFunctionType` in `coercionLKind` and `coercionRKind`, using `mkFunctionType` in `mkFunCo` is consistent with this choice. Moreover, using `mkFunctionType` does not regress the performance of any test case we have in GHC's test suite.
Showing
- compiler/GHC/Core/Coercion.hs 3 additions, 2 deletionscompiler/GHC/Core/Coercion.hs
- testsuite/tests/typecheck/should_fail/T21328.hs 11 additions, 0 deletionstestsuite/tests/typecheck/should_fail/T21328.hs
- testsuite/tests/typecheck/should_fail/T21328.stderr 4 additions, 0 deletionstestsuite/tests/typecheck/should_fail/T21328.stderr
- testsuite/tests/typecheck/should_fail/all.T 1 addition, 0 deletionstestsuite/tests/typecheck/should_fail/all.T
Loading
Please register or sign in to comment